Suite & Dependency Lifecycle
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
Research direction
Start by tracing the class activator and the existing suite execution and re-entry behavior described in the issue. Then review the proposed Suite and Suite Dependents concepts, including IAfterSuite. Done requires an agreed lifecycle model and clear execution and dependency-ordering behavior, but the issue does not name files or tests to run.
Written by the indexing model from the issue text.
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.
- Dominant language
- C#
- Stars
- 5
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bitcobblers/ZeUnit
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bitcobblers/ZeUnit#71 ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
bitcobblers/ZeUnit#64 ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
bitcobblers/ZeUnit#28 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
bitcobblers/ZeUnit#27 ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
bitcobblers/ZeUnit#26 ·
All issues in bitcobblers/ZeUnit
Similar issues
-
再現済み 要トリアージ 誤判定
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
yksr-melt/Meltype#421 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Facepunch/sbox-public#12063 · 1 comment ·
Maintainers usually reply within 2 days
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
facioquo/stock-indicators-dotnet#2316 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
eriknihlen/OpenAC#219 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ObsidianMC/Obsidian#548 ·
Maintainers usually reply within 1 day