# Purpose of TestBase in Ocaramba: Centralizing Test Diagnostics and Failure Handling

> Discover the purpose of TestBase in Ocaramba, the core utility for centralizing Selenium test diagnostics, screenshots, and failure handling. Enhance your test suites today.

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

---

**TestBase** is the foundational utility class in the Ocaramba framework that centralizes failure diagnostics, screenshot capture, and verification handling for Selenium-based test suites.

The **accenture/ocaramba** repository provides a robust automation framework for .NET Selenium testing. Understanding the purpose of **TestBase in Ocaramba** is essential for teams looking to standardize their test infrastructure, as this class serves as the root for all project-specific base classes and ensures consistent error reporting across NUnit, Xunit, and MSTest implementations.

## What Is TestBase in Ocaramba?

Located in [`OcarambaLite/TestBase.cs`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/TestBase.cs), **TestBase** is an abstract utility class designed to be inherited by project-specific base classes such as `ProjectTestBase`. Rather than containing test cases itself, it encapsulates cross-cutting concerns like failure detection, screenshot generation, and verification message handling. This design pattern allows development teams to implement common teardown logic once and inherit it across every test project in the solution.

## Core Responsibilities of TestBase

The class fulfills four primary responsibilities that standardize test execution and reporting.

### Capturing Screenshots and Page Source on Failure

The `SaveTestDetailsIfTestFailed` method (lines 38-53 in [`OcarambaLite/TestBase.cs`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/TestBase.cs)) automatically detects test failures and captures diagnostic artifacts. When `driverContext.IsTestFailed` returns true, the method triggers `driverContext.TakeAndSaveScreenshot()` and `SavePageSource`, aggregating the resulting file paths into a string array for attachment to test reports.

### Persisting HTML Page Source for Debugging

The `SavePageSource` method (lines 65-68) provides a thin wrapper around `DriverContext.SavePageSource`, using the test title as the filename. This ensures that the exact state of the DOM is preserved whenever a test fails, enabling developers to inspect element states offline without re-running the entire suite.

### Managing Verification Message Collections

Unlike traditional assertions that halt execution immediately, Ocaramba supports "soft" verifications through the `IsVerifyFailedAndClearMessages` method (lines 71-84). This method checks the `VerifyMessages` collection maintained by `DriverContext`, clears the accumulated messages, and returns a boolean indicating whether any verification failures occurred during the test run.

### Serving as a Central Extension Point

By inheriting from **TestBase**, project-specific classes like `ProjectTestBase` (found in [`Ocaramba.UnitTests/ProjectTestBase.cs`](https://github.com/accenture/ocaramba/blob/main/Ocaramba.UnitTests/ProjectTestBase.cs)) gain immediate access to diagnostic utilities without duplicating code. This inheritance chain ensures that any future enhancements—such as additional logging formats or new artifact types—propagate automatically to every test project in the organization.

## Implementing TestBase in Your Test Projects

To leverage the purpose of **TestBase in Ocaramba**, create a project-specific base class that inherits from it and integrates with your chosen testing framework.

### Creating a ProjectTestBase Class

The following pattern demonstrates how `ProjectTestBase` extends `TestBase` to wire up NUnit lifecycle hooks:

```csharp
// Ocaramba.UnitTests/ProjectTestBase.cs
public class ProjectTestBase : TestBase
{
    private readonly DriverContext driverContext = new DriverContext();

    protected DriverContext DriverContext => driverContext;
    
    public TestLogger LogTest
    {
        get => driverContext.LogTest;
        set => driverContext.LogTest = value;
    }

    [SetUp]
    public void SetUp()
    {
        // Test initialization logic
    }

    [TearDown]
    public void AfterTest()
    {
        // Failure detection and cleanup
    }
}

```

### Automating Failure Diagnostics in TearDown

The true power of **TestBase** manifests in the teardown phase, where it coordinates failure detection and artifact collection:

```csharp
[TearDown]
public void AfterTest()
{
    // Determine failure state from NUnit context or verify messages
    DriverContext.IsTestFailed = TestContext.CurrentContext.Result.Outcome.Status == TestStatus.Failed
                                 || DriverContext.VerifyMessages.Count != 0;

    // Capture screenshot and page source if failed
    var attachments = SaveTestDetailsIfTestFailed(DriverContext);
    SaveAttachmentsToTestContext(attachments);

    // Fail test if verification messages were collected but no exception thrown
    if (IsVerifyFailedAndClearMessages(DriverContext) &&
        TestContext.CurrentContext.Result.Outcome.Status != TestStatus.Failed)
    {
        Assert.Fail();
    }
}

```

### Implementing Soft Verifications

Use the verification system to collect multiple assertions before failing:

```csharp
public void VerifyElementIsVisible(IWebElement element)
{
    if (!element.Displayed)
    {
        DriverContext.VerifyMessages.Add("Element not visible");
    }
}

// Later in the test or teardown:
if (IsVerifyFailedAndClearMessages(DriverContext))
{
    Assert.Fail(); // Forces failure if any verify messages exist
}

```

## Relationship Between TestBase and DriverContext

While **TestBase** provides the high-level API for test lifecycle management, the heavy lifting occurs in `DriverContext` (located in [`Ocaramba/Helpers/DriverContext.cs`](https://github.com/accenture/ocaramba/blob/main/Ocaramba/Helpers/DriverContext.cs)). **TestBase** delegates screenshot generation and page-source persistence to this helper class, maintaining separation of concerns: `DriverContext` manages the Selenium `IWebDriver` instance and file I/O, while **TestBase** orchestrates when these actions occur based on test outcomes.

## Summary

- **TestBase** lives in [`OcarambaLite/TestBase.cs`](https://github.com/accenture/ocaramba/blob/main/OcarambaLite/TestBase.cs) and serves as the root class for all Ocaramba test projects.
- The `SaveTestDetailsIfTestFailed` method automates screenshot and page-source capture when tests fail.
- `IsVerifyFailedAndClearMessages` enables soft assertion patterns by aggregating verification errors until teardown.
- Inheriting from **TestBase** through a project-specific class like `ProjectTestBase` ensures consistent failure handling across NUnit, Xunit, and MSTest frameworks.
- The class delegates driver operations to `DriverContext` while maintaining the public API surface for test lifecycle management.

## Frequently Asked Questions

### What is the difference between TestBase and ProjectTestBase in Ocaramba?

**TestBase** is the framework-provided utility class containing generic methods for failure handling and diagnostics. **ProjectTestBase** is a user-created class (typically found in [`Ocaramba.UnitTests/ProjectTestBase.cs`](https://github.com/accenture/ocaramba/blob/main/Ocaramba.UnitTests/ProjectTestBase.cs)) that inherits from **TestBase** and adds project-specific configurations such as driver initialization, logger setup, and framework-specific attributes like NUnit's `[SetUp]` and `[TearDown]`.

### How does TestBase handle screenshots when a test fails?

The `SaveTestDetailsIfTestFailed` method checks the `IsTestFailed` property of the `DriverContext` instance. If true, it invokes `TakeAndSaveScreenshot()` and `SavePageSource()` on the driver context, returning an array of file paths that can be attached to test reports or CI/CD artifacts.

### Can I use TestBase with testing frameworks other than NUnit?

Yes. Because **TestBase** resides in the framework-agnostic `OcarambaLite` assembly and contains no framework-specific attributes, you can inherit from it in Xunit, MSTest, or SpecFlow projects. Each framework-specific implementation (such as those in `Ocaramba.Tests.Xunit` or `Ocaramba.Tests.MSTest`) provides its own lifecycle hooks that call the base **TestBase** methods.

### What are "verification messages" in the context of TestBase?

Verification messages are strings added to `DriverContext.VerifyMessages` during test execution to implement soft assertions. Unlike hard `Assert` statements that stop execution immediately, these messages accumulate until `IsVerifyFailedAndClearMessages` is called (typically in teardown), allowing multiple validations to run before the test finally fails.