Unit Test Guidelines and Best Practices for Sitecore Content Hub

Hi Sitecorians! 👋

If you have worked with Sitecore Content Hub scripts, you know it plays a crucial role in ensuring that scripts in Sitecore Content Hub remain stable, predictable, and safe to deploy. Because scripts interact with entities, relations, taxonomy, and settings, developers must design tests that are fast, isolated, and independent of the actual Content Hub environment.

The goal of this blog is simple: help you build a clean, fast, and reliable unit testing setup for your Content Hub scripts.

Introduction

When writing unit tests for Sitecore Content Hub scripts, a few core practices can make your test suite cleaner, faster, and far easier to maintain. Content Hub scripts interact with entities, relations, settings, and the execution context, so approaching tests correctly ensures stability without relying on the actual CH environment.

In our projects we use xUnit as the testing framework, and over time, several patterns have consistently proven effective. This article brings those practices together in a consolidated form.

Mocking the Content Hub Environment

A fundamental rule in testing Content Hub scripts is to avoid connecting to the real environment. The more you mock, the cleaner and faster your tests become. Mocking the Content Hub context, relations, and entities allows you to focus on the script logic without creating unnecessary data in the platform.

Mocks also ensure that tests can run locally, on CI/CD pipelines, and in shared environments without depending on actual Content Hub connectivity or credentials. This keeps the test suite predictable and completely isolated.

Using Constructor and Dispose for Reusable Test Entities

There are cases where using mocks becomes impractical — for example, when a script interacts heavily with relations or metadata structures. In such situations, creating lightweight test entities is unavoidable.

Instead of creating these entities repeatedly inside every test method, it is far more efficient to initialize them once in the test class constructor. This improves performance and keeps the test implementation clean. When the test run is complete, the Dispose() method handles cleanup so that the environment remains free of leftover test data.

Here is a typical structure:

public class MyTest : IDisposable
{
    public MyTest()
    {
        // Create reusable entity
        _targetAsset1Type = _entityHelpers.GetOrCreateEntity(
            SettingMockFactory.TargetAssetType1Identifier,
            AssetType.DefinitionName
        );

        Assert.NotNull(_targetAsset1Type);
    }

    public void Dispose()
    {
        // Cleanup test entities
        _mClientFactory.Client.Entities.DeleteAsync(_targetAsset1Type.Id.Value);
    }
}

If your project uses a common BaseTest class, reusable entities can be registered for cleanup using the disposal list. For example:

_assetMedia = _taxonomyHelpers.CreateOrGetTaxonomyEntity(
    SettingMockFactory.AllowedAssetMediaAIdentifier,
    AssetMedia.DefinitionName,
    true
);

Assert.NotNull(_assetMedia);
AddToDisposeList(_assetMedia);

This approach ensures that all test entities are automatically removed after test execution

Working With Settings in Unit Tests

Content Hub settings are ideal for mocking because they are stored as JSON. Instead of fetching real settings from the platform, tests can inject a mocked configuration directly into the script under test.

A common example looks like this:

var validateMetadataScript = new ValidateAssetMetadataStatus(mockContext.Object, _client)
{
    RequirementsSetting = SettingMockFactory.GetValidateAssetMetadataStatusMock()
};

Inside the script, you can prevent actual API calls by checking whether the script is running in test mode. If settings are not injected when testing, the script throws a clear exception:

if (!runInTestMode)
{
    RequirementsSetting = await GetRequirementsSetting();
}
else if (RequirementsSetting == null)
{
    throw new ArgumentNullException(
        nameof(RequirementsSetting),
        "Please inject requirements settings mock when running tests!"
    );
}

This pattern ensures that tests remain independent of Content Hub, while still allowing the script to behave normally in a real environment.

Conclusion

Testing Content Hub scripts efficiently requires a balance between mocking, reusable setup, and controlled configuration. By abstracting the CH environment, creating reusable test entities through the constructor, cleaning them up via Dispose(), and injecting mocked settings, you can achieve a test suite that is fast, clean, and fully reliable.

These practices help ensure that script logic is thoroughly validated without depending on or polluting the actual Content Hub environment, resulting in safer deployments and more stable implementations.