If `TestDescriptor` is actually a `TestExecution`,...

# minutest

[natpryce]

If TestDescriptor is actually a TestExecution, then it can register resources that need to be cleaned up at the end of the test run…

[dmcg]

I'd like to see a use-case.

[natpryce]

Spawning a redis service as a background process, for example

[natpryce]

Or creating a resources in a message broker

[dmcg]

I know what cleanup is! What I mean is, how would it look - compared to after, afterAll, how you square the difference between single test execution and all test executions

[natpryce]

What we currently do with lazy global properties.

[natpryce]

that only lets us clean up what the OS cleans up at the end of the process.

[natpryce]

(And the JUnit TestEngine API does not constrain execution to once per process or even single threaded, so maybe we shouldn’t rely on that)

[dmcg]

At the moment I use JUnit 5's @AfterAll to clean up when I have globalish resources (an SSH tunnel in particular)

[dmcg]

I can see that it would be good to have a pure way to do that, but the devil is in the detail. A test execution is too early - you'd need a afterAll exections

[natpryce]

AfterAll runs after all tests in a class, which couples resource lifetime to the way one groups/organises tests to clarify communication to the reader. Which is what I’d like to avoid.

[dmcg]

So you want TestsExecution

[dmcg]

which I can see would be nice

[dmcg]

but couples usage to your runner

[natpryce]

Well… if you use Jupiter, you can continue to use @AfterAll. But if you use the MinutestTestEngine, there’d be another mechanism.

[natpryce]

👋 But it’s all a bit hand-wavy at the moment 👋