# How Ocaramba Implements Non-Stopping Assertions with Verify

> Discover how Ocaramba implements non stopping assertions using the Verify class. Learn how exceptions are managed allowing your tests to continue executing.

- Repository: [Accenture/ocaramba](https://github.com/accenture/ocaramba)
- Tags: how-to-guide
- Published: 2026-02-23

---

**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`](https://github.com/accenture/ocaramba/blob/main/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`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/Verify.cs) is:

```csharp
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:

```csharp
// 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:

```csharp
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`:

```csharp
// 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`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/Verify.cs) | Core static class providing overloaded `That` methods; catches assertion exceptions, logs them, and stores `ErrorDetail` objects. | [Verify.cs](https://github.com/accenture/ocaramba/blob/master/OcarambaLite/Verify.cs) |
| [`OcarambaLite/DriverContext.cs`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/DriverContext.cs) | Holds the `VerifyMessages` collection; provides helpers for screenshots and page-source saving used by `Verify`. | [DriverContext.cs](https://github.com/accenture/ocaramba/blob/master/OcarambaLite/DriverContext.cs) |
| [`OcarambaLite/TestBase.cs`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/TestBase.cs) | Utility methods for test teardown; `IsVerifyFailedAndClearMessages` checks the `VerifyMessages` collection and clears it. | [TestBase.cs](https://github.com/accenture/ocaramba/blob/master/OcarambaLite/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.