XCUITests — Soft Assert and Hard Assert

Nishith Shah
Quality Engineering University
2 min readApr 11, 2021
Photo by Gustas Brazaitis on Unsplash

This post covers how to handle Assertion Failure in XCUITests. Test scripts can be very robust and large. Assertions are the best method to perform any kind of validations in the tests. When an assertion fails the test script stops execution unless handled in some form.

There are two types of assertions:

  1. Hard Assertions
  2. Soft Assertions
open var continueAfterFailure: Bool

@property continueAfterFailure
- Determines whether the test method continues execution after an XCTAssert fails.
- By default, this property is YES, meaning the test method will complete regardless of how many
- XCTAssert failures occur. Setting this to NO causes the test method to end execution immediately
- after the first failure occurs, but does not affect remaining test methods in the suite.
- If XCTAssert failures in the test method indicate problems with state or determinism, additional
- failures may be not be helpful information. Setting `continueAfterFailure` to NO can reduce the
- noise in the test report for these kinds of tests.

Hard Assertions

  • A Hard Assertion is a type of assertion that instantly throws an exception when a assert statement fails and continues with the next test in the test suite.
  • To achieve this, we need to handle the Assertion error which is thrown with a catch block like the Swift block.
  • It will execute entire Test Case but at the end it will mark the Test Case as Fail.

If you have multiple assertions in a test they might increase in specificity. You don’t want to run the second if the first fails, it’s just noise.

class TestCase: XCTestCase {
override func setUpWithError() throws {
continueAfterFailure = false
}
func test_pushingAnElementOnTheStack() throws {
XCTAssertEqual(1, 2)
XCTAssertEqual(9001, 9001)
}
}

Soft Assertions

  • Soft Assertions is definitely the assertions type that does not throw an exception when a assertion fails and continues in the next phase after the assert statement.
  • This is usually used when our test requires many assertions to execute and the user wants to execute all the assertions / code before failing / skipping the tests.

You want to run the second if the first fails, it’s just noise.

class TestCase: XCTestCase {
override func setUpWithError() throws {
continueAfterFailure = true
}
func test_pushingAnElementOnTheStack() throws {
XCTAssertEqual(1, 2)
XCTAssertEqual(9001, 9001)
}
}

Let me know — along with any questions, comments, or feedback that you might have on https://www.linkedin.com/in/nshthshah.

--

--