engine lifecycle / test case isolation #75
Description
TestInstance.Lifecycle vs MTE Engine lifespan
Currently the Extension does its own management of when to create new Engine instances vs re-using an existing one. (Users choose between MTEExtension or IsolatedMTEExtension.)
JUnit5 introduced its own way to manage test instance lifecycle. A test class may set TestInstance.Lifecycle.PER_CLASS to share state on the instance across invocation of all its test methods.
Is it worthwhile for us to keep our own way to specify whether an engine is shared between tests, or should we drop that part and say the engine's lifespan is the same as the test instance's?
Related Work: There may be other work in progress for managing resources across JUnit tests: junit-pioneer/junit-pioneer#348 started out being about TempDirectory, but may be generalized to support arbitrary types of resources.
Relation of Engine & Game lifecycle to JUnit Before/After hooks
JUnit will call methods annotated with BeforeAll, BeforeEach, AfterAll, AfterEach, as it enters and exits your Test methods.
A clearer way to describe some MTE setup code is according to the game engine's lifecycle: run before or after Engine initialization, or on transition to StateLoading or StateIngame.
GameEngine does provide an interface to subscribe to its state changes, but the interface we have with the most detailed lifecycle methods is the EngineSubsystem.
Should we provide a convenient way to define methods on the test class that are run at these points in the subsystem lifecycle?
What about the ComponentSystem lifecycle methods?
Neither gestalt's Modules nor ModuleEnvironment look to have lifecycle methods, but some things that handle Terasology's ModuleEnvironments call methods on whatever EnvironmentSwitchHandler is in the Context.