I would like to adhere to the fail-fast methodology when writing automated end-to-end tests, but there's a problem I see with the methodology that I'm not sure how to get around. What happens when there are multiple unrelated points of failure in a test that are introduced at the same time? Your test will fail fast on the first one and not run to completion, so you won't know about the rest of them. You won't be able to even find out about the rest of them until the first point of failure is fixed. This can lead to a frustrating back-and-forth with developers as they fix one problem and you immediately bring them a new one.

The specific scenario I'm thinking of is entering data into a form on a webpage. If the DOM properties you use to access elements on the page have changed for some reason and your test can no longer find them, wouldn't you rather know about all of them at once, so you can bring a list of them to the developer?

1 Answer 1


How you handle this is largely based on your tool set. Many tools have a continue on failure option for each test step. What might help in these cases is before doing a test that interacts with elements, first do an element verification test. I got into this habit when using Telerik Test Studio, which saves the element locators in a repository of sorts I can update all the ones that failed in the element verification test and they would then work for any tests that called those element locators.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.