Handling Assertions in Automation related tools (TestNG)

As a developer assertions are used to red flag critical errors, errors from which programs can not recover. Its pretty convenient and lays out clearly the assumptions a developer has made on the flow of the program. On the flows which are in critical path of logic flow developers tend to use Assertions.

Assertions are equally popular in Testing community, specially with Automation developers. Automation developers use assertions to verify is system responded to a test case in the way it was expected to. Failure on system's part to respond in expected way causes an Assertion Exception.

Unlike in development, in Automation a tester may not want the entire testing module to be skipped if one of the test cases failed or led to Assertion Exception. At the same time he would still want to flag this error to underlying framework like TestNG. Welcome to the world of Soft Assertions which were introduced exactly to handle situation like above.

Its a developer's prerogative when to use Assertion and when to use SoftAssert classes. Typically at places where you do not want rest of test case to be executed on failure of a core module, for example login, since rest of the test cases would fail, you are more likely to use normal Assertion classes. However for testcases failure of which does not negatively impact other code in a test case, you can leverage SoftAssert classes.

 Example

import org.testng.asserts.SoftAssert;

public class TestCases { 
   
    @Test
    public void sampleFailure() {
      private SoftAssert softAssert = new SoftAssert();
      softAssert.assertTrue(false); 
      System.out.println("program still continues");
      softAssert.assertAll(); 
    }
}