How Ocaramba Implements Non-Stopping Assertions with Verify

Ocaramba implements non-stopping assertions through the static Verify class, which executes assertion delegates inside try-catch blocks, stores exceptions in DriverContext.VerifyMessages, and allows the test to continue executing.

The Ocaramba test automation framework provides a robust soft-assertion mechanism that prevents individual verification failures from aborting test execution. Unlike standard unit test assertions that throw exceptions immediately, Ocaramba's non-stopping assertions collect all failures and report them at the end of the test run.

How the Verify Class Implements Soft Assertions

The Verify class in OcarambaLite/Verify.cs provides the core infrastructure for non-stopping assertions through a delegate-based execution model.

The Action Delegate Pattern

The Verify.That method accepts a params Action[] array, allowing multiple assertion delegates to be passed in a single call. Each Action contains a standard assertion call (such as Assert.AreEqual or Assert.IsTrue). The method signature in OcarambaLite/Verify.cs is:

public static void That(DriverContext driverContext, bool enableScreenShot, bool enableSavePageSource, params Action[] myAsserts)

This overload iterates through each delegate and calls the single-assertion overload Verify.That(DriverContext, Action, bool, bool) for individual execution.

Exception Handling and Artifact Capture

The single-assertion implementation wraps each delegate in a try-catch block. When an assertion fails and throws an exception, the catch block performs several diagnostic actions before allowing the test to continue:

• Screenshot capture: Calls driverContext.TakeAndSaveScreenshot() when enableScreenShot is true
• Page source saving: Invokes driverContext.SavePageSource when enableSavePageSource is true
• Exception logging: Writes the failure to NLog via Logger.Error(..., e)
• Failure storage: Creates an ErrorDetail instance and adds it to driverContext.VerifyMessages

The exception is then swallowed rather than re-thrown, allowing the loop to proceed to the next assertion delegate.

Storing Failures in DriverContext

The DriverContext class maintains a VerifyMessages collection that persists throughout the test execution. Each failed assertion adds an ErrorDetail object containing the exception and timestamp. This collection serves as the central repository for all non-stopping assertion failures, accessible via this.DriverContext.VerifyMessages within test methods.

Code Examples for Non-Stopping Assertions

Basic Multiple Assertion Usage

The following example demonstrates running three independent assertions without stopping on failure:

// Inside a test method derived from TestBase
Verify.That(
    this.DriverContext,
    () => Assert.AreEqual("Welcome", HomePage.Title),
    () => Assert.IsTrue(HomePage.IsLoggedIn),
    () => Assert.AreEqual(5, HomePage.MenuItems.Count));

All three assertions execute regardless of individual failures. Any exceptions are collected in DriverContext.VerifyMessages for later inspection.

Enabling Screenshots and Page Source

To capture diagnostic artifacts when assertions fail, enable the screenshot and page source flags:

Verify.That(
    this.DriverContext,
    enableScreenShot: true,
    enableSavePageSource: true,
    () => Assert.AreEqual("Error", ErrorPage.Message),
    () => Assert.IsFalse(ErrorPage.HasStackTrace));

When either assertion fails, Ocaramba automatically saves a screenshot and the HTML page source to the test output directory.

Validating Results After Execution

After executing soft assertions, check the verification results using TestBase.IsVerifyFailedAndClearMessages:

// After all Verify.That calls
bool verifyFailed = this.IsVerifyFailedAndClearMessages(this.DriverContext);
if (verifyFailed)
{
    Assert.Fail("One or more soft assertions failed – see logged verify messages.");
}

This method returns true if any verify messages exist, clears the collection to prevent cross-test contamination, and allows the test framework to mark the test as failed while preserving all failure details in the logs.

Key Implementation Files

File	Description	Source Link
OcarambaLite/Verify.cs	Core static class providing overloaded That methods; catches assertion exceptions, logs them, and stores ErrorDetail objects.	Verify.cs
OcarambaLite/DriverContext.cs	Holds the VerifyMessages collection; provides helpers for screenshots and page-source saving used by Verify.	DriverContext.cs
OcarambaLite/TestBase.cs	Utility methods for test teardown; IsVerifyFailedAndClearMessages checks the VerifyMessages collection and clears it.	TestBase.cs

Summary

• Ocaramba implements non-stopping assertions through the static Verify class, which accepts multiple Action delegates containing standard assertions.
• Each assertion executes inside a try-catch block in Verify.That(DriverContext, Action, bool, bool), allowing exceptions to be caught and stored rather than thrown.
• Failed assertions are stored as ErrorDetail objects in DriverContext.VerifyMessages, with optional screenshots and page source captured via DriverContext methods.
• The TestBase.IsVerifyFailedAndClearMessages method checks for accumulated verification failures at the end of a test and clears the message collection to prevent state leakage between tests.

Frequently Asked Questions

What is the difference between Verify and standard Assert in Ocaramba?

Standard Assert methods throw exceptions immediately when a condition fails, aborting the current test execution. The Verify class implements soft assertions that catch these exceptions, store them in DriverContext.VerifyMessages, and allow the test to continue executing subsequent code. This enables multiple validation points within a single test without stopping at the first failure.

How do I check if any soft assertions failed?

Use the IsVerifyFailedAndClearMessages method from the TestBase class. Pass the DriverContext instance to this method; it returns true if any verification messages exist in DriverContext.VerifyMessages. The method also clears the collection to prevent failures from one test affecting subsequent tests. Typically, you call this at the end of your test method and fail the test explicitly if it returns true.

Can I capture screenshots only when Verify assertions fail?

Yes. When calling Verify.That, set the enableScreenShot parameter to true. When an assertion delegate throws an exception, the catch block in Verify.That automatically calls driverContext.TakeAndSaveScreenshot(). Similarly, setting enableSavePageSource to true captures the HTML page source via driverContext.SavePageSource. These artifacts are saved to the test output directory with timestamps for diagnostic purposes.

Where are verification failures stored during test execution?

Verification failures are stored in the VerifyMessages collection of the DriverContext class. Each failure is encapsulated as an ErrorDetail object containing the exception, timestamp, and optional screenshot or page source references. This collection persists throughout the test execution, allowing you to inspect failures via this.DriverContext.VerifyMessages before calling IsVerifyFailedAndClearMessages to reset the state.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}