4 ms·

Selenium tests are just generally a pain - even when written manually I've seen these fail more often from structural changes to the code rather than actual bre

Selenium tests are just generally a pain - even when written manually I've seen these fail more often from structural changes to the code rather than actual breakages. I might be biased, but QA in Production [1] is my preferred approach now that we have great rollout systems [2][3] and ways to do verification testing in production [4]. [1] https://martinfowler.com/articles/qa-in-production.html https://martinfowler.com/articles/qa-in-production.html [2] https://split.io https://split.io [3] https://launchdarkly.com https://launchdarkly.com [4] https://logrocket.com https://logrocket.com

saimiam 9y ago
But a structural change could be a bug. The iron rule of software is that changes in the product have a reason behind them. If your UI tests break because of a structural change, that break should be anticipated while the corresponding story/feature is being developed. In the past, when we faced test failures which seemed annoying and trivial, we discovered that the real reason why we never anticipated those failures was because we never know which tests to run for the feature or page in question. We are hoping to fix that by using robust, semantic tags for tests. So, where we used to have tags like @TC_123456 we now use tags like @Login_UI etc.