Feature toggles aren’t just for production code. Feature toggles are also a powerful technique to change the behaviour of your automated end-to-end tests without changing code.
Once upon a time there lived a couple who loved playing massively multiplayer online role-playing video games with each other (World of Warcraft or Destiny or something). The thing about these games is that they’re a bit like exercise/fitness where you need to keep playing them to keep your score high, and if you don’t you play them (or exercise) enough your score (or fitness) starts dropping which makes it much less fun overall.
So playing these games all went well for the couple, for a while.
I try to avoid incorporating any or layout/style based checks or locators into my automated end to end tests since these typically change more often leading to a higher test maintenance burden.
But I did have a circumstance recently where I wanted to check that a change I dynamically made to a page was reflected in the resultant web element’s style.
Let’s imagine hypothetically you were working on software that placed landmines in a minefield grid and you had a function that given the dimensions of a minefield, and a safe cell, you had to randomly place a certain number of landmines in the other cells of the grid. It looks something like this:
Which codebase is better?
Whilst I find the WebDriver API useful, I also find it lacking in certain methods that I wish to do repeatedly throughout my tests.
If you saw my talk at GTAC last year, ‘your tests aren’t flaky‘, then you’re probably aware of my view on flaky tests actually being indicative of broader application/systems problems that we should address over making our tests less flaky.
But what if you’re in a situation where you work with a system where you can’t feasibly improve the reliability? Say you’ve got a domains page that should show you a list of available domains but since it’s using an external third-party service it sometimes just shows nothing?