For quite a long time (since 2007) I am working on test automation. GUI testing was a huge part of that and it was always something I never really enjoyed. I did have a reason, so as many of my coleagues, due to a lot of facts. It is not only hard to get a green build in our CI pipeline but it is also nearly impossible to execute all of the tests locally before commiting the code. At the moment I am working at eBay/Marktplaats and we have a pretty large set of Selenium tests (around 2500). The website itself (http://marktplaats.nl) is built using Service Oriented Architecture and we are trying to move towards using microservices but that is still a long way. At the moment our website consists of 5 front-end applications and around 75 back-end services. At the same time there are a lot of different databases. In some cases services share the same database and in some case they have a dedicated one. Unfortunately, when it comes to a Selenium test, it is always implemented as an integration test, meaning that all services and databases are supposed to be up and running. Due to the fact of having around 40 enginers in 6 teams working on the same codebase it is hard to get a green build. People often push broken code and, since front-end depends on every service, a small bug somewhere deep in a specific service can break the whole flow.
At some point I decided to rethink the UI testing strategy and started to look for something else. I had to find an answer to a lot of questions. What do we really want to test with Selenium? Can we reduce the scope of Selenium tests, make them run 2-3 seconds on average per test and drastically reduce the amount of flakiness in our CI? Do we really want a layout test to break due to a bug in back-end service? Can we make Selenium tests just part of the front-end repo without maintaining separate tests and stubs repos? And last but not least: can we make executing tests locally easier for everyone in the team?