Thetype exposes the following members.
Returns true if the Start(Action) method is running.(Inherited from TestFixture.)
Returns true if the instance has been disposed.(Inherited from TestFixture.)
Returns true if the fixture has been initialized.(Inherited from TestFixture.)
Used by unit test classes to persist arbitrary name/value information across individual unit tests.(Inherited from TestFixture.)
Verifies that the fixture instance has not been disposed.(Inherited from TestFixture.)
Verifies that the fixture instance's Start(Action) method is executing.(Inherited from TestFixture.)
Performs application-defined tasks associated with freeing, releasing, or resetting unmanaged resources.(Inherited from TestFixture.)
Releases all associated resources.(Overrides TestFixtureDispose(Boolean).)
Determines whether the specified object is equal to the current object.(Inherited from Object.)
Serves as the default hash function.(Inherited from Object.)
Gets the Type of the current instance.(Inherited from Object.)
Creates a shallow copy of the current Object.(Inherited from Object.)
(Inherited from TestFixture.)
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.
INTERNAL USE ONLY: Resets the fixture state.(Overrides TestFixtureReset.)
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.)
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 AddFixtureTFixture(String, TFixture, ActionTFixture, Int32), passing the Action as a function that performs any custom configuration.via
|ComposedFixture.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|
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:
So when the ComposedFixture starts, it'll start the database/workflow engine fixtures first as group=0 and then start your 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.