Functionnal perimeter

[nfroidure]

What should be the functionnalities of the API. My advice is that we should mimic the user inputs by simulating events as closest as possible.

For that purpose, i think we could do something like an object for each input device and methods faking actions on those devices. By example, for the mouse:

mouse.move(fromElement, toElement); // simulating mouseover ?
mouse.moveTo(element); // simulating mouseover ?
mouse.click(element); // mousedown, mouseup, click
mouse.dbclick(element) // ...

The event listener callbacks are called synchronously so i think we do not need Promises at all, maybe for higher level API but is it in the scope of this library ?

[nfroidure]

Comment request @goldoraf @n1k0 @kud
History:

• Twitter: https://twitter.com/goldoraf/status/389328071574437888
• Gist (french): https://gist.github.com/goldoraf/451c3b66523773d6aa8d

[nfroidure]

Still in a "device oriented" API, for non-usual devices, we could do feature detection like here https://github.com/nfroidure/Commandor/blob/9cabc88d37541005f6decd4e2bfdaf3e42685f0a/tests/EventSimulator.js#L133

It could lead to mocha tests looking like that:

describe('Error notices', function() {
    beforeEach(function() {
        showAnErrorNotice();
    });
    it('Should disappear when clicking on the close button',function() {
        mouse.click($('close-button'));
    });
    it('Should disappear when focusing and pressing the enter key',function() {
        keyboard.tabTo($('close-button'));
        keybord.enterKey($('close-button'));
    });
    if(tactileArea.isConnected()) {
        it('Should disappear when touching the close button',function() {
            tactileArea.touch($('close-button'));
        });
    }
    if(pointingDevice.isConnected()) {
        it('Should disappear when touching the close button',function() {
            pointingDevice.point($('close-button'));
        });
    }
});

[goldoraf]

In my opinion, we should provide different types of APIs, like chai does for assertions. Your idea of a device-oriented is great, it'll allow to nicely separate event-simulating code per device, and could form a perfect low-level API. Building a DSL-oriented API on top of it will be a piece of cake.

On the subject of promises, if they are not mandatory in the low-level API, I think we must use them in the DSL one, even if some methods return an immediately-fullfilled promise (waitFor-type methods need promises to avoid callback hell, trust me). By always return promises, we'll make sure to never beak the promises chain.

[MattiSG]

Hi there!

Sorry, that might be very clear, but I don't get it from the outside :-S So: how exactly does that project differ from WebDriver?

The API you're trying to define in this issue, for example, is already available in the JSONWireProtocol.

Moreover, if you intend to stay only in userland JS, you will encounter limitations due to events not being trusted by the browser.
On the other hand, if you try to externalize the code so as to control the browser from the outside, you'll likely end up with a WebDriver-style implementation or, if you stick to JS, with a clone of the Phantom ecosystem.

I might be completely off on that one, so please let me know if I didn't understand what you're trying to achieve with this library :)

Best regards,
Matti

[nfroidure]

I'm probably not the best person to talk about WebDriver/Selenium since i do not use it.

But i can tell you why we decided to create Effroi. Mainly cause we are Karma users and nothing similar currently exists for this test runner. Here is the related plug-in : https://github.com/francejs/karma-effroi . We also think it could be a good basis for projects like PhantomJS/CasperJS etc... since their event simulation efforts aren't currently put in common.

I know Effroi will never be as close to real device than an OS level event simulation library. But my libraries/applications aren't testing if events are trusted. It is a really specific use case (third party JavaScript for instance).

See Effroi like the library new developers can embed easily. It does the job for most use cases and it is as simple as adding a line in your package.json.

[MattiSG]

my libraries/applications aren't testing if events are trusted. It is a really specific use case

Checking if events are trusted is indeed a specific use case.

Having a web application that behaves differently depending on whether the events it receives are trusted by the browser is much more common. Testing a click with any key modifier, or any keyboard shortcut in your app, will not give the same results.

Anyway, I kind of see the point of adding UI triggers to Karma tests (but I'm not a Karma user myself, so can't be sure).
In this case, though, to answer the “Functional perimeter” question, it is probably important to acknowledge the fact that Karma was built to be a unit testing framework :)

(source: Karma thesis)

Adding UI simulation is tricky in what it allows to do, as the boundary between using it to check view triggers and doing e2e/integration testing is often blurry.

Don't get me wrong: I just wanted to save you possibly wasted effort on duplicating existing libraries (exactly because “event simulation efforts aren't currently put in common” ;) ), and this issue seemed like it was asking that question.

If you're sure you wouldn't be better served by keeping unit tests away from the UI and using integration testing for it, then best of luck with effroi! :)

[nfroidure]

I do not use Effroi for integration testing (ie testing an application in its production environment). To me, it is the role of tools like CasperJS.

I'm using it for unit testing of libraries evolving events listeners and standalone components (Web Components will be the most important use case for instance). In fact, it is currently discussed on the Karma's repo karma-runner/karma#828

"Don't get me wrong:" : I do. Feel free to not use Effroi. From my point of view, i'm wasting time by answering you, not by bringing Effroi to the community. Will you troll each repo that is not fitting with your needs ?

[kud]

And that's why Effroi (or any code project in fact) shouldn't be on FranceJS, thank you guys, I'll create an issue to move this project out of FranceJS.

[nfroidure]

@kud unrelated to me