Base classes

To simplify unit testing, several base classes are available for your XUnit test classes.

TestBase class

This class is provided by Neos and should be used (directly or indirectly) as a base class for your test classes.

This is the most generic class, exposing basic methods. If you need to test some specific rules (ex: entity validation rule, entity view), you should use domain or application test classes wich extend TestBase class with associated methods.

For more information about how to use theses classes, see this article.

Mocker property

To simplify your test, an AutoMocker instance is available via this property. This instance is configured to :

Redirect NeosLogger logs to XUnit output.
Configure default return value for common cases. For example, all methods that return a Result return Result.Ok().

The AutoMocker Verify method is automatically called when the test class is disposed.

Derived classes, exposed later in this section, add additional configurations to the AutoMocker instance.

GetMock method

This method is just a shortcut for Mocker.GetMock. The two following instructions are equivalent:

Mock<ICustomerRepository> m1 = GetMock<ICustomerRepository>();
Mock<ICustomerRepository> m1 = Mocker.GetMock<ICustomerRepository>();

Informations about the constructor

You must provide a constructor with a ITestOutputHelper parameter and pass it to the base class constructor.

public class TestClass : TestBase
{
    public TestClass(ITestOutputHelper output)
        : base(output)
    {
    }
}

This parameter is necessary to redirect logs to XUnit ouput.

Strict modes

The constructor also accepts two optional parameters, strict and superStrict, both false by default. The domain and application base classes described below, and the test classes generated in your modules (ApplicationTest, SavingRuleTest, ValidationRuleTest, etc.), accept and forward them too.

Parameter	Effect when `true`
`strict`	Every setup of the AutoMocker mocks must have been called when the test ends, otherwise the test fails.
`superStrict`	A call on a mock that matches no setup throws an exception. Every expected call must be set up, even a trivial one.

Pass them by name to the base class constructor:

public class SavedTests : ApplicationTest
{
    public SavedTests(ITestOutputHelper output)
        : base(output, strict: true)
    {
    }
}

In strict mode, a setup that a test may legitimately leave unused (in a theory where only some cases call it, for example) can be excluded from the verification with the NonVerifiable extension method, from the GroupeIsa.Neos.Shared.XUnit namespace:

using GroupeIsa.Neos.Shared.XUnit;

GetMock<ICustomerService>()
    .Setup(s => s.IsActive(It.IsAny<string>()))
    .Returns(true)
    .NonVerifiable();

Caution

superStrict also applies to the in-memory repositories of the domain and application base classes: every repository call of the test must then be set up. Prefer strict for tests that use these repositories.

Base classes for domain layer tests (entities)

All base classes in this layer automatically configure entity repositories in the AutoMocker instance.

When creating a validation rule or an event rule on an entity, a corresponding test class will be created on the domain test project of the module.

For example if a Saved event rule is created for a Territory entity of a Partners module, a SavedTests.cs class will be created in the directory EventRules/Territory of the project Partners.Domain.Tests.UnitTests.

For more information see :

Base classes for application layer tests (entity views & server methods)

All base classes in this layer automatically configure entity repositories and entity view repositories in the AutoMocker instance.

We creating a server method or an entity view rule (event, validation), a corresponding test class will be created on the application test project of the module.

For example if a Retrieving event rule is created for a EnabledEmployeeView entity view of a Partners module, a RetrievingTests.cs class will be created in the directory EventRules/EnabledEmployeeView of the project Partners.Application.Tests.UnitTests.

For a server method CopyOrder of a Sales module, a CopyOrderTests.cs class will be created in the directory Methods or the project Sales.Application.Tests.UnitsTests.

For more information see :

They expose the following methods:

GetEntityViewRepositoryMock

This method allows to get the entity view repository mock associated to an entity view type:

Mock<IEntityViewRepository<ICustomerView>> customerViewRepositoryMock = GetEntityViewRepositoryMock<ICustomerView>();

GetEntityViewRepository

This is a shortcut for GetEntityViewRepositoryMock<TEntityView>().Object.

Those classes expose a method to get the entity view repository:

IEntityViewRepository<ICustomerView> customerViewRepository = GetEntityViewRepository();

Table of Contents