Suite & Dependency Lifecycle #40
Description
The current structure around re-entry and execution needs to be re-evaluated, the idea of a singleton lifecycle and chain execution are things that need to be thought about more. Currently, this seems to be a double concern for the class activator, and figuring out the lifecycles of that gets complicated. Instead it is easier to think about the activators as the dependencies of something that defines the lifecycle of the tests.
Suite
Current working Idea: Test Class Inheritance to Suite.
- Unless specified by test that belongs to a class without inheritance will be treated as transient, it will create a transient class to run the test method and throw the object away after to run the next test. All test can now be run in parallel. This should be the core behavior, and most tests should need to reason about execution order.
- The singleton lifecycle for the class should allow you to create behavior of execution. Different ideas for how to order test in a way that makes chain of execution obvious
- ordered aka the order they are written in the class
- custom, allow some inherited language syntax to order the execution of tests.
Suite Dependents
By default every test class is a Suite, or at least will be treated this way, so marking a class test class with the marker interface will allow the sort order of the execution to make sure that some test classes are run before others. IAfterSuite<TTestClass> would have no implementation details, but a test for the interface would allow dependencies to be tracked.