Click or drag to resize

ITestFixture Interface

INTERNAL USE ONLY: Defines the behavior of a Neon Xunit test fixture.

Note Note
All test fixture implementations must inherit from TestFixture to work properly. Do not attempt to create a fixture from scratch that implements this interface.

Namespace:  Neon.Xunit
Assembly:  Neon.Xunit (in Neon.Xunit.dll) Version: 2.14.0
public interface ITestFixture : IDisposable

The ITestFixture type exposes the following members.

Public propertyIsRunning
Returns true if the fixture has been started.
Public propertyState
Used by unit test classes to persist arbitrary name/value information across individual unit tests.
Public methodDispose
Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.
(Inherited from IDisposable.)
Public methodOnRestart

Called when an already started fixture is being restarted. This provides the fixture an opportunity to do some custom initialization.

Note Note
This method is intended only for use by test fixture implementations. Unit tests or test fixtures should never call this directly.
Public methodReset
INTERNAL USE ONLY: Resets the fixture state.
Public methodStart
Starts the fixture if it hasn't already been started including invoking the optional Action the first time Start(Action) is called for a fixture instance.

Xunit test fixtures are designed to provide initialize global state that tests can then reference during their execution. Typical scenarios include:

  • Starting a database server and prepopulating it with a schema and data to test database access code.
  • Starting a Docker service such that REST endpoints can be tested.
  • Initializing a cluster and then configuring it with certificates, routes, services etc. and then performing tests against the actual swarm.

Test fixture lifecycle:

  1. First, you'll need create your Xunit test class and have it derive from IClassFixture, where TFixture identifies the fixture.
  2. The Xunit test runner reflects the test assemblies and identifies the test classes with [Fact] test methods to be executed.
  3. For each test class to be executed, the test runner first creates an instance of the test fixture. This is created before one before any of the test classes are instantiated and any test methods are called.
  4. The test runner creates a new instance of the test class for each test method to be invoked. The test class constructor must accept a single parameter with type TFixture. The test class constructor should call Start(Action) to initialize the fixture, passing an optional Action that does any custom initialization for the test.

    The Action parameter is generally intended for internal use when implementing custom test fixtures.

    Test fixtures are designed to be aware of whether they've been initialized or not such that only the first call to Start(Action) will perform any necessary initialization (including calling the custom action) and any subsequent calls will do nothing.

    Note Note
    Some test fixtures may define a different different initialization method.
  5. The test runner will continue instantiating test class instances and calling test methods using the test fixture state setup during the first test.
  6. Once all of the test methods have been called, the test runner will call the test fixtures Dispose method so that it can clean up any state.
Thread Safety
Instance members of this type are not safe for multi-threaded operations.
See Also