Selenium · Browser automation foundations
Should you retry failed Selenium tests automatically?
Short answer
Retry sparingly as a temporary safety net, not as a substitute for fixing flakiness. One or two retries can protect a release from known infrastructure noise, but every retry must be logged and investigated.
A retry hides a failure on the first attempt. That is acceptable when the cause is a known transient such as a Grid node restart, but dangerous when it masks a real race in the product or the test. The default should be to fix the cause.
public class RetryAnalyzer implements IRetryAnalyzer {
private int attempts = 0;
private static final int MAX_ATTEMPTS = 1;
@Override
public boolean retry(ITestResult result) {
if (attempts < MAX_ATTEMPTS) {
attempts++;
return true;
}
return false;
}
}
@Test(retryAnalyzer = RetryAnalyzer.class)
public void checkoutWorks() {
new CheckoutPage(driver()).completeOrder();
}- Retry the smallest scope possible, ideally a known flaky test rather than every test
- Keep the retry count low; repeated retries multiply runtime and hide systemic issues
- Record that a test passed on retry and report it separately from a clean pass
- Quarantine tests that need constant retries and assign an owner
- Do not retry assertion failures that indicate deterministic product bugs
- Ensure retries do not leak data or duplicate side effects
A retry analyzer may be instantiated or reused in ways that make a simple counter unsafe under parallelism. Verify the runner's behaviour or use a thread-safe implementation. The retry decision should be visible in the report so nobody mistakes a retried pass for a healthy test.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When is an automatic retry justified?
- 2Why is a retry counter unsafe under parallelism?
- 3How do you report a test that passed on retry?
- 4What would make you remove retries entirely?
Say it in the interview
I treat retries as a temporary safety net for known infrastructure noise, not as a fix for flaky tests. I scope them to specific tests, keep the count low and report retried passes separately so they are visible. Deterministic assertion failures should never be retried. If the retry rate grows, I stop adding retries and investigate the root cause.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Selenium mock interview and get scored feedback on depth, clarity and confidence.