Setting up End-to-End testing (for Nyssetutka.fi) using Nightwatch.js, Selenium and ChromeDriver and running the tests in a headless Chrome instance was super easy.
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.
Many of the components we design for the web are made to save space. It’s interesting that we work so hard to save space on a medium where we have infinite space to work with.
Similar to asset injection, head management follows the same idea: we can dynamically attach data to the render context in a component's lifecycle, and then interpolate those data in template.