Unidriver - Full-API vs. Best-Practice

[hepiyellow]

2 Birds

I believe that the Unidriver project tries to kill 2 birds with one shot.

• Write once - test on any platform
• Best-Practice API for App Testing

Currently Rejected (NOT Best-Practice)

WSR drivers are using several methods which are rejected according to UniDriver's Best-Practice approach.
Here is WSR's ReactAdapter which implements those.

These methods arte considered by WSR as methods that we DO want to expose to consumers !

Full API

I believe it's for the best to separate these 2 concerns, and thus offer 2 sets of APIs:

• Full
• Best-Practice

How To

Either:

1. Create a separate project, 'unidriver-fullthat uses@unidriver` under the hood.
2. Create a unidriver-full project, and have unidriver consume it under the hood, and expose only the best-practice API. (restricted)
3. Embed the Full-API inside unidriver, and put the bad-practice methods as nested methods such as _.

  export type UniDriver<T = any> = {
    $: (selector: Locator) => UniDriver<T>;
    $$: (selector: Locator) => UniDriverList<T>;
    text: () => Promise<string>
       ...
       _: {
         focus: ()=>...,
         blur: ()=>...,
         ...
       }
  }

Options 3 is by far the most simple to maintain,
and could help avoid rejections of the library when it is published as Open-Source.

I think potential consumer's first concern is that this library CAN deliver its first premise (write once - test on any platform), and only think about best-practice as a secondary "nice-to-have".

So...?

---

FYI @shlomitc @mykas

[shlomitc]

I think that approach 2 should be the leading one.

De-facto, having only the best practices driver approach limits us from writing our tests. Yes, in some cases we must retrieve properties which are more than just pure interactions. For example, retrieving the attributes of some dom node.

Since this collision of the best API vs. full API, we had to write our own implementation for only for some adapter, which is bad, because it means we do not comply to the unified driver approach.
Here's our React adapter:
https://github.com/wix/wix-style-react/blob/master/test/utils/unidriver/ReactBase.js

I don't think we should have a different project trying to mimic unidriver's approach, as it means we need another testing library. also, it makes sense to abstract functionality over a full api, and not extend it.

That's why I opt for the unidriver-full approach.

[GabiGrin]

@shlomitc I think that enabling things like.blur() on browser tests is an anti-pattern.
To implement it you will need to simulate events via scripts which is far from what an user would do.

In other words, my main point is that the "full API" you need is only needed to do "unit-ish" tests
I'd like to create an API for the user / user interface, not the DOM. My dream is using the same driver interface for both the web-app and mobile app, and not using the same test for testing internals

I suggest we do a short discussion about it, it's a really interesting topic and I think the conclusions should be documented and passed on. @shahata