Make waiting for event loop implicit or explicit in all cases

Zombie.js does not start to process its event queue until you call browser.wait().

In some browser methods, like click(), this call to wait is implicit, meaning the method calls wait() for you or returns the lazy promise returned by browser.fire(). Then again some browser methods, like fill() ignore the lazy promise returned by browser.fire() and return this. In the latter case you must call browser.wait() in your test code explicitly. This is unexpected and not well documented and leads to confusing test code.

I personally would prefer an implicit approach, so all browser methods emitting events would implicitly run wait() by returning the promise returned by browser.fire(), but either way, all the methods should have the same behaviour.

[jliuhtonen]

Fair enough.

I was referring more to the easiness of constructing a mental model of how Zombie works and how to write (and read) code that triggers DOM events inside it. IMO it would make things easier if there no special cases and exceptions for doing similar things (interacting with the page DOM).

Sure, one can implement a utility that does the waiting or call .wait() always explicitly, but that’s beside the point.

Btw. the way I discovered this was that I tried to implement a waiting assertion that checks periodically whether a given predicate is true or times out with an assertion error after a given period. Using one of the methods that do not wait of course I ended up always timing out, because the event loop was not run at all. After this I read the source and learned that .wait() does more than waiting. I now understand why it is, but it’s still a surprising implementation detail that the event loop does not run by itself and you have to call a method called .wait() (sometimes) to make it run.

The reason I brought this up is that I really like Zombie’s approach to headless browser testing with Node and I hope that it can be made even better in the future. Thanks for your work! 👍

[assaf]

Yes, definitely some people will find it more useful if fill also did a wait, just like some people find it more useful that you can chain multiple fill. Neither of these shortcuts will please everyone, I just find the current API to be the most useful.

You asked about making wait implicit or explicit for all methods. Explicit is already supported: call the method without a callback, then follow up with a call to wait.