[Feature]: ExplicitAttribute behaviour opt-out

[teneko]

Problem Statement

Currently if annotating tests with ExplicitAttribute, these tests cannot be mixed with non-explicit tests. Which is a bummer, when your test surface is complex and you have to write a wrapper, that simplifies the control of which tests you want to test including explicit tests. Currently you only can select the subset of a test pool which is explicit or not explicit.

Proposed Solution

A way to opt-out the usage ExplicitAttribute as I would have not annotated the tests with ExplicitAttribute.

It could be solved by

• built-in MSBuild-driven opt-out for behaviour of ExplicitAttribute or
• making ExplicitAttribute pattern-matched so we mimick the behaviour of ExplicitAttribute but annotate it by ConditionalAttribute or similiar approach, to make it opt-out.

Alternatives Considered

#if FEATURE_FLAG_A
[ExplicitAttribute]
#endif

But.. well.. make that for every usage of ExplicitAttribute.. 😆

Feature Category

Test Discovery / Attributes

How important is this feature to you?

None

Additional Context

No response

Contribution

• I'm willing to submit a pull request for this feature

[teneko]

This is more about to treat all explicit tests as non-explicit so I do not have to run TUnit twice for one test axis/slice/pool/category, that contains explicit and non-explicit tests. Currently I actually have to model my test surface in-code so that I am able to compute which TUnit tests I have to run complementary when navigating from a command-line wrapper for testing purposes only.

[thomhurst]

This is more about to treat all explicit tests as non-explicit

Maybe explicit isn't what you want then? Can you achieve what you want with custom properties + filtering on those?

[teneko]

Context: I have a verify gate, to run all possible tests without external tests, without fancy stuff what also would not be able inside a ci/cd environment or tests that are very expensive and long-running. these tests must not be included in the happy/default path, I mean in the dotnet test -c Release path. Think of it as a sanity check. I for sure can flip the logic and test a category and exclude by another category, here namely Explicit, but then I need to filter.. just not so convenient. But that is not the problem because I need to filter anyway and that is alread solved by a wrapper.

Problem: I would like to preserve dotnet test -c Release as my solution-wide sanity check and hide human-unmanable filter logic behind a wrapper. It is just the thing now that I have to run a category twice, when said category contains at least one explicit, thus I need to mirror that knowledge into the wrapper, so that I can split into two TUnit test runs, one run where I run the catogory where explicit calls are implictly skipped, because a non-explicit test is contained and then the same category with the additional category "Explicit". So it would just be nice having a way to treat explicit tests as non-explicit, to reduce complexity (the additional test run and the mirroring of the info if the lane/category has one explicit or not).