Boost Your Test Coverage Without Breaking Your Flow

Chamila Ambahera
4 min readNov 13, 2024

--

Why Soft Assertions

In traditional testing methods, often called hard assertions, if one test fails, the whole thing stops right there. While this can be useful in some cases, it isn’t always the best way to go. For example, think about testing a login form where you want to check several things, like the title, the success message, and whether the buttons are showing up. If the first test fails, the other checks get skipped, which can make it tricky to figure out what went wrong in that test run.

Soft assertions allow you to check multiple conditions simultaneously. Even if some conditions fail, the rest of the test will continue running, and all failures will be reported at the end. This method is ideal for enhancing test coverage without creating bottlenecks or losing important test insights.

When to Use Soft Assertions

While soft assertions can be very helpful, there are particular scenarios where they shine:

  1. UI Testing with Multiple Verifications: When verifying multiple aspects of a UI component (e.g., button visibility, colours, labels), soft assertions let you catch all discrepancies in one run without breaking the flow.
  2. Complex Data Validations: For cases involving complex data structures where multiple fields or properties need validation, soft assertions help check each field’s accuracy in a single pass.
  3. Form Validation Scenarios: In testing forms, you often have multiple fields to validate. Soft assertions let you check all form fields in a single run, making it easier to locate any failing fields.
  4. End-to-End Tests with Several Points of Failure: When testing entire workflows or scenarios with several potential failure points, soft assertions ensure that you capture every failure, which is especially useful for long test cycles.

Now, let’s dive into examples and implementations across various frameworks.

Soft Assertions in Action

Let’s walk through using soft assertions in Java with JUnit and TestNG.

Example 1: Java with JUnit and AssertJ

JUnit doesn’t offer built-in soft assertions, but the AssertJ library fills the gap with a SoftAssertions feature. Here’s how you can use it:

import org.assertj.core.api.SoftAssertions;
import org.junit.jupiter.api.Test;

public class SoftAssertionExample {

@Test
public void testMultipleUIElements() {
SoftAssertions softAssertions = new SoftAssertions();

// Mock values for the sake of example
String actualTitle = "Login Page";
String actualMessage = "Welcome Back!";
boolean isLoginButtonVisible = false; // This will intentionally fail

// Perform multiple soft assertions
softAssertions.assertThat(actualTitle).isEqualTo("Login Page");
softAssertions.assertThat(actualMessage).isEqualTo("Welcome Back!");
softAssertions.assertThat(isLoginButtonVisible).isTrue(); // This assertion will fail

// Collect and report any failures at the end
softAssertions.assertAll();
}
}

Output: Even though the login button visibility check fails, other assertions will still run, and all failures will be reported together at the end of the test.

Example 2: Java with TestNG’s SoftAssert

TestNG provides its own SoftAssert class. This example demonstrates soft assertions in a scenario where a registration form validation checks multiple fields:

import org.testng.annotations.Test;
import org.testng.asserts.SoftAssert;

public class RegistrationFormTest {

@Test
public void testFormFields() {
SoftAssert softAssert = new SoftAssert();

String actualUsername = "User123";
String actualPassword = "pass";
boolean isSubmitButtonEnabled = false;

// Performing multiple checks without stopping at the first failure
softAssert.assertEquals(actualUsername, "User123");
softAssert.assertTrue(actualPassword.length() >= 8, "Password length check failed");
softAssert.assertTrue(isSubmitButtonEnabled, "Submit button should be enabled");

// Gather all assertion failures
softAssert.assertAll();
}
}

Output: All failures are reported at the end, giving you a clear view of any issues across form fields.

Best Practices for Using Soft Assertions

  1. Choose the Right Scenarios: Use soft assertions when you want to collect multiple errors at once but avoid them in situations where a single failure makes the rest of the test invalid.
  2. Clear Reporting: Make sure your failure messages are descriptive. In some frameworks, you may need to add custom failure messages to ensure they’re easy to understand in the test report.
  3. Don’t Overuse Soft Assertions: In critical tests where one failure invalidates the entire scenario (like security or core functionality tests), stick with hard assertions.
  4. Group Related Assertions: Organize soft assertions by the feature or component they test. This approach ensures that your tests remain readable and maintainable.

Final Thoughts

Soft assertions are a valuable tool for testers, allowing thorough validations without interrupting the flow of testing. They are particularly useful in scenarios involving user interfaces, forms, and data validation, where halting at the first failure is not practical. By adhering to the best practices outlined here, you can enhance the resilience and clarity of your test suite, which will help your team debug issues more quickly and effectively.

Give soft assertions a try in your next test case, and watch your testing flow become smoother and more insightful!

--

--

Chamila Ambahera
Chamila Ambahera

Written by Chamila Ambahera

Principle Automation Engineer | Arctic Code Vault Contributor | Trained Over 500 engineers

No responses yet