Open mkobit opened 5 years ago
Hmm good point.
I'm not sure that there's an easy fix for this one. Because of the nature of the JUnit5 runner, skip is implemented as throwing an exception in the test method execution. In order to start that execution, the chain of fixture setup is invoked.
Does plain old JUnit, instantiate an instance of the test class just in order to not invoke its method I wonder? Probably not, but it has separate discovery and execution phases that the JUnit5 runner, based as it is on Streams, does not.
As you can probably tell by this stream of consciousness, I'm thinking this through. I'll let this issue mull for a while.
I'm not sure that there's an easy fix for this one. Because of the nature of the JUnit5 runner, skip is implemented as throwing an exception in the test method execution. In order to start that execution, the chain of fixture setup is invoked.
That makes sense. I do like the current flexibility of minutest
in that it just uses the dynamic test feature of JUnit under the hood, but dynamic tests don't support the various extensions APIs yet (https://github.com/junit-team/junit5/issues/378). @TestTemplate
or a test engine could possibly solve this, but that is an entirely different track of code to support. I wonder if this issue could be solved if https://github.com/junit-team/junit5/issues/378 was complete (just pondering).
Version:
1.7.0
I was trying out the
dev.minutest.experimental.SKIP
feature and noticed that it looks likederiveFixture
/modifyFixture
/probably other pieces are executed for a nested context that is skipped. I was using Mockito mocks in a fixture and was modifying the behavior in each nested context. At the most nested context, I had a handful of tests that I wanted to skip because they were not implemented yet, so I thought I would try outSKIP
. I saw test failures due to using strict mocks, so the expectations set on the mocks were throwingorg.mockito.exceptions.misusing.UnnecessaryStubbingException
after the test because it looks like the behavior settings were called even though the nested context was skipped.My expectation is that the whole buildup would not be executed for skipped contexts.
Here is an example that I think demonstrates my expectations better than my explanation:
Output:
My expectation is that
would not need to be called since those tests are skipped.