Does WebDriverJS/WebDriverIO promises make javascript the language of choice for Selenium?

Question

I don't believe any other Selenium-compatible language supports promises which seems like a game-changer when it comes to dealing with waits. Since no other Selenium-compatible language supports this, why would anyone use another language?

Answer 1

TL;DR: convenience of programmers not the only deciding factor when selecting the implementation language.

---

Promises are necessary when programming page events and response to asynchronous AJAX calls.

But for browser automation testing (which is supposed to mimic user's interaction with a page), they are not necessary at all. User usually initiates an action, waits for the results, and then initiates another action depending on the results. User rarely starts two different actions simultaneously.

So for mimicking the user, rich library of waits is more helpful, like Python's ExpectedConditions.

Also, asynchronous processing is much harder to reason about.

Because debugging code is twice as hard as writing it, if you write code as clever as you can, by definition you are unable to debug it :-)

So promises are clever and necessary evil for GUI developers, but for test automation they add superfluous complexity. Asynchronicity adds value for GUI, but in test automation, maintainability and code flexibility is much more important, IMHO (to deliver reliable tests for a lower cost).

Also, JavaScript is far from preferred language for many teams, and if you have few thousands test written and maintained for your application in different language, there is little value of throwing it all out of the window and start with JavaScript. For team starting on a green field, limiting to single language for both GUI development and automated tests might make sense, but for legacy projects - not so much.

And Python is also excellent language (superior to JavaScript, IMHO) to automate text parsing, system administration etc, which are important part of test automation. I do not see benefits of switching all these tasks to JavaScript.

JavaScript is slowly improving, and it is likely here to stay for GUI development for a long time, but Python is likely the closest language to the one programmers will be using 100 years from now: read The Hundred Year Language by Paul Graham who coined the term "blub paradox" - btw this article is promoting Lisp, not Python, but also worth a read.

I am not rejecting promises (it is a clever concept and very useful for even-driven programming), but reliability of automated tests requires different concepts, like data-driven programming.

Our GUI developers are creating some unit tests in Protractor, but we feel that Python is better fit for most of the other test automation tasks.

Another aspect: duplication of effort is acceptable if quality is extra important, like in aviation: many aviation components use two sets of processor, from different manufacturers and programmed by two different teams in two different languages, to detect subtle misunderstanding in requirements, undetected errors in CPU, interfaces, etc. In such situation, using different language for testing would be not just an option, but a requirement. In a similar way, one of my friend was using C++ (for speed) when writing Wall Street trading algorithms, but scripting language for testing them (for productivity). I hope nuclear power stations are handled like this too, but have no personal experiences with it :-)

Answer 2

Why would anyone use another language?

Documentation and number of answered questions on sites like stackoverflow. Languages like Java give much better search results. We use JavaScript and WebDriverJS, but sometimes it is hard to find an answer when you are stuck.

Promises are a game-changer when it comes to dealing with waits

Yes, but not per se a positive one. Promises could lead to deep nesting or you have to add the await/async keyword everywhere. It adds an extra complexity to coding that most test engineers do not have a good understanding of, although this is getting better due to the increased use of modern JS frameworks in teams.

To handle the new complexity the WebDriverJS team added a promise manager, which they are now going to remove in the near future.

Personally I think a procedural flow for tests is fine and maybe even better, because it is easier to grasp. Just like Peter described in his answer. Users do not do their actions async on a website. They click and wait.