Hi HN,<p>recently there have been a lot of discussions about Chrome's dominance on the Web leading to many websites being broken for alternative browsers.<p>I think one of the reasons for this is that browser automation is hard and manual testing is often limited to the browser developers themselves use.<p>I've distilled my best practices for browser test automation into the following project and hope it helps other developers to test their projects with more browsers:<p><a href="https://github.com/blueimp/wdio" rel="nofollow">https://github.com/blueimp/wdio</a><p>It's a Docker setup for WebdriverIO with automatic screenshots, image diffing and screen recording support for containerized versions of Chrome and Firefox.<p>It also includes Webdriver configurations to test an app running in Docker with Safari Desktop, Safari Mobile and Chrome Mobile via Appium and Internet Explorer and Microsoft Edge in a Windows 10 virtual machine.
wrt "Chrome's dominance in test automation", I'd like to point out that the puppeteer team is working on Firefox support.<p><a href="https://www.npmjs.com/package/puppeteer-firefox" rel="nofollow">https://www.npmjs.com/package/puppeteer-firefox</a>
<a href="https://aslushnikov.github.io/ispuppeteerfirefoxready/" rel="nofollow">https://aslushnikov.github.io/ispuppeteerfirefoxready/</a>
I've been running WebdriverIO in Docker for a while now, as follows:<p>On my CI server (using GitLab CI), I run a Node Docker image, and connect the Selenium Firefox [1] or Selenium Chrome [2] Docker image to it. I then install WebdriverIO, and tell it to find Selenium on that container's hostname.<p>This works, but is a little bit brittle, and I've had to pin the Selenium image versions because something broke at a certain point and it didn't seem worth it to fix it yet.<p>Which is to say: I'd very much be in the market for using the containerised versions of Chrome and Firefox, if there were instructions for doing so in CI - the primary use case for browser automation, in my opinion.<p>I realise that this might not be your intended usage, but figured I'd provide this feedback just in case it is.<p>[1] <a href="https://hub.docker.com/r/selenium/standalone-firefox/" rel="nofollow">https://hub.docker.com/r/selenium/standalone-firefox/</a><p>[2] <a href="https://hub.docker.com/r/selenium/standalone-chrome/" rel="nofollow">https://hub.docker.com/r/selenium/standalone-chrome/</a>
I've tried various automated browser tools and they all were flakey. (e.g. Randomly hangs while waiting for an element to appear when the element is already there.). Is this is a bug in my testing code or are all these types of tools actually that unreliable?
I may be out of the loop but one of the reasons I went with a different library to WDIO was the ability to remotely test any browser without having drivers installed on the device. Has this changed with Selenium?
I'm mostly used to Capybara / Selenium (mostly chromedriver) and have a reasonable level of Javascript/Node but I'm really not sure how I would use this project beyond the setup of having the different browsers running, am I supposed to load those config with WebdriverIO using `remote`?
The docker-comjpose file raises the question is there some handy way for versioning the used docker images in the docker-compose.yml, like pip / npm have? You would usually want to control for browser versions in this kind of testing, no?