When Nightwatch runs a test, it processes its commands in a list known as the command queue. This list manages the asynchronous execution of the commands defined in that test. As a queue, the command queue generally follows the rule of first in, first out (FIFO). The first command you call in a test is the first executed when the test runs. The second command is called next, followed by the next command up until the last command added, which becomes the last command executed.
What I always find hardest to figure it when it comes to unknown systems, it’s ‘how things fit together’. These project might have great documentation, but how the ecosystem plays together is usually left as an exercise for the reader. This happened to me again when diving into frontend testing. I figured out how to get nightwatch+selenium-standalone+chromedriver+chrome working somehow, without fully understanding each part in the puzzle. I went with Nightwatch because I like the syntax and it seems one of the obvious options nowadays. That works until I updated some dependencies and broke everything again. So I took some time to figure out how these things fit together and what is really needed for me tests. I’ve learned that Selenium is the godmother of modern frontend testing. It’s a framework with bindings for multiple languages. To decouple the server from the actual browsers, it invented “Selenium RC” as a protocol. That lead to the development of the WebDriver W3C standard which replaces Selenium RC is newer versions and is implemented for the most common browsers (Chrome -> Chromedriver, Firefox -> FirefoxDriver).
In Part 1, I discussed running Selenium and Chrome headless mode on Docker. Originally the plan was to use AWS CodePipeline and AWS CodeBuild to run the Docker container and the smoke tests for my website.