---

Rerun failed tests using testng-failed.xml

When to use?

Here and there after some bug fixes, as a test mechanization engineer we are required to run just the bombed tests announced by test computerization suite. Running just the bombed tests approve the bug fixes rapidly. 

How to achieve?

Running just the bombed tests is genuinely straightforward as TestNG offers inborn help for this. At whatever point a test suite is run utilizing the testng.xml record then after the test execution, a testng-failed.xml document gets made in the test-yield envelope. Later on, we can run this record simply like we run the testng.xml document. As this record just monitors the bombed tests, so running this document, runs the bombed tests as it were. 

Retry failed tests automatically using IRetryAnalyzer

When to use?

Now and again, the test execution report concocts a few disappointments that are not a direct result of the issues in the application. The basic reason for these issues may be identified with the test condition arrangement or some incidental server issue. So as to ensure that the disappointment detailed in the test report are authentic and not only erratic cases, we can retry running the bombed experiments to kill bogus negative tests brings about our test reports. 

How to achieve?

For retrying the disappointment trials consequently during the trial itself, we have to execute the IRetryAnalyzer interface gave by TestNG. The IRetryAnalyzer interface give techniques to control retrying the trials. Here, we will abrogate the retry() technique for IRetryAnalyzer to ensure the trials if there should arise an occurrence of disappointment with specififed number of retry limit. The remarks in the code bit make it self-explainatory. 

package com.artoftesting.test;
import org.testng.IRetryAnalyzer;
import org.testng.ITestResult;
 
public class RetryAnalyzer implements IRetryAnalyzer {
  
 //Counter to keep track of retry attempts
 int retryAttemptsCounter = 0;
  
 //The max limit to retry running of failed test cases
 //Set the value to the number of times we want to retry
 int maxRetryLimit = 1;
 
 //Method to attempt retries for failure tests
 public boolean retry(ITestResult result) {
 if (!result.isSuccess()) {
 if(retryAttemptsCounter < maxRetryLimit){
 retryAttemptsCounter++;
 return true;
 }
 }
 return false;
 } 
}

For the demo, I am making a fake test technique underneath and deliberately bombing it utilizing the assert.fail() strategy. Here, we will set the @Test explanation's retryAnalyzer property with RetryAnalyzer.class that we made previously. 

@Test(retryAnalyzer = RetryAnalyzer.class)
    public void intentionallyFailingTest(){
     System.out.println("Executing Test");
     Assert.fail("Failing Test");
    }

Test Output 

===============================================
Test suite
Total tests run: 2, Failures: 1, Skips: 1
===============================================

Here, we can see that the quantity of runs for the technique are shown as 2 with one disappointment and one skipped. The primary run of the test technique when bombed will be set apart as Skipped and afterward the test will run again because of the rationale determined in the RetryAnalyzer. 

Presently, there is only one issue, we have to set the retryAnalyzer quality in every one of the @Test explanation. To manage this we can execute IAnnotationTransformer interface. This interface gives the capacity to adjust the testNG comment at runtime. In this way, we will make a class actualizing the IAnnotationTransformer and make it set the RetryAnalyzer for @Test explanations. 

package com.artoftesting.test;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
 
import org.testng.IAnnotationTransformer;
import org.testng.IRetryAnalyzer;
import org.testng.annotations.ITestAnnotation;
 
public class FailureRetryListener implements IAnnotationTransformer {
  
 //Overriding the transform method to set the RetryAnalyzer
 public void transform(ITestAnnotation testAnnotation, Class testClass, 
 Constructor testConstructor, Method testMethod) {
 IRetryAnalyzer retry = testAnnotation.getRetryAnalyzer();
 
 if (retry == null)
 testAnnotation.setRetryAnalyzer(RetryAnalyzer.class);
 }
}

Having made an audience, we can determine it in the testNG.xml document this way 

<listeners>
   <listener class-name="com.artoftesting.test.FailureRetryListener"/>
</listeners>

Presently, we don't need to set the retryAnalyzer in each @Test comment. Having the audience indicated in the testng.xml document will make it work for all the tests. 

PS: If you need to add retry usefulness to just constrained arrangement of test strategy than simply set the @Test explanations with retryAnalyzer quality with RetryAnalyzer.class, there is no compelling reason to execute IAnnotationTransformer and including the audience in the testng.xml record.