Click or drag to resize

CodeFixture Class

Used to execute some custom code while ComposedFixture is starting subfixtures. This is typically used to perform additional configuration of a ServiceMap, etc. to configure components like NeonService instances for integration testing.
Inheritance Hierarchy

Namespace:  Neon.Xunit
Assembly:  Neon.Xunit (in Neon.Xunit.dll) Version: 2.14.0
public class CodeFixture : TestFixture

The CodeFixture type exposes the following members.

Public methodCodeFixture
Constructs the fixture.
Protected propertyInAction
Returns true if the Start(Action) method is running.
(Inherited from TestFixture.)
Protected propertyIsDisposed
Returns true if the instance has been disposed.
(Inherited from TestFixture.)
Public propertyIsRunning
Returns true if the fixture has been initialized.
(Inherited from TestFixture.)
Public propertyState
Used by unit test classes to persist arbitrary name/value information across individual unit tests.
(Inherited from TestFixture.)
Protected methodCheckDisposed
Verifies that the fixture instance has not been disposed.
(Inherited from TestFixture.)
Protected methodCheckWithinAction
Verifies that the fixture instance's Start(Action) method is executing.
(Inherited from TestFixture.)
Public methodDispose
Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.
(Inherited from TestFixture.)
Protected methodDispose(Boolean)
Releases all associated resources.
(Overrides TestFixtureDispose(Boolean).)
Public methodEquals
Determines whether the specified object is equal to the current object.
(Inherited from Object.)
Protected methodFinalize
(Overrides TestFixtureFinalize.)
Public methodGetHashCode
Serves as the default hash function.
(Inherited from Object.)
Public methodGetType
Gets the Type of the current instance.
(Inherited from Object.)
Protected methodMemberwiseClone
Creates a shallow copy of the current Object.
(Inherited from Object.)
Public methodOnRestart

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

Note Note
This method is intended only for use by test fixture implementations. Unit tests or test fixtures should never call this directly.
(Inherited from TestFixture.)
Public methodReset
INTERNAL USE ONLY: Resets the fixture state.
(Overrides TestFixtureReset.)
Public methodStart
Starts the fixture if it hasn't already been started including invoking the optional Action when the first time Start(Action) is called for a fixture instance.
(Inherited from TestFixture.)
Public methodToString
Returns a string that represents the current object.
(Inherited from Object.)

A common use case for this is to deploy a cluster of services in-process with databases and/or workflow engines deployed as local Docker containers by other test fixtures. The idea is to add a CodeFixture via AddFixtureTFixture(String, TFixture, ActionTFixture, Int32), passing the Action as a function that performs any custom configuration.

Note Note
CodeFixture really doesn't do anything by itself. It's purpose is simply to provide a mechanism for adding and executing your custom code to the ComposedFixture.

You action code can then do things like initialize the database schema and test data as well as initializing a ServiceMap by setting the environment variables and configuration files for any NeonService instances that will also be deployed for the test. Many integration test scenarios follow this pattern:

  1. Implement a unit test derived from IClassFixture<ComposedFixture>.
  2. In the test constructor, add any database and/or workflow engine fixtures as group=0. These fixtures will start in parallel and will be running before any fixtures in subsequent groups are started.
  3. Then add a CodeFixture to the cluster fixture via AddFixtureTFixture(String, TFixture, ActionTFixture, Int32), passing your action as group=1.
  4. Your action should perform any custom configuration.
  5. Add your NeonService and/or other fixtures as group=2 or beyond, as required.

So when the ComposedFixture starts, it'll start the database/workflow engine fixtures first as group=0 and then start your CodeFixture as group=1 and your custom action can initialize the database and perhaps configure a ServiceMap. Once your action has returned, ComposedFixture will start the fixtures in any remaining groups with a configured database and ServiceMap before the test framework starts executing your tests cases.

Thread Safety
Instance members of this type are safe for multi-threaded operations.
See Also