I've pushed that version - you can try it on for style

I've taken the opportunity to rename the parts of the RuntimeNode tree, so that we now have Node, Context and Test. The typealias formerly known as Test is now Testlet. These names were in the main package, but I think that you'll only use them if you're writing transforms, which were and are experimental.

You may be able to tell that I'm clearing the decks for a 1.0 release

Which further begs the question of the product and package names

Should the name

minutest

stick, or is it too punny? If we keep it, I could register minutest.org.uk (fly the flag) and move the code into uk.org.minutest

I wanted minu.test, but the .test TLD is reserved apparently

one thing I will say is it’s kinda hard to search for

Do we need another naming discussion? 😃

Suggestion: Separatest ✊

One thing I would love (and I’m not even sure it’s feasible in any sane way) is support for a tuple style fixture without having to declare a dedicated data class. I know it’s just because I’m lazy but it would reduce friction significantly.

Hmm, what would that look like @robfletcher ?

I’m not sure, that’s the problem. I think what I want is Go-like structs

I’m going to mess around and see if I can do it with inner classes when I get a chance

Personally I like that the Fixture expresses and bounds the test universe.

yes, I do too

Pretentious, mois?

I just find myself writing a little data class for almost every test

and I’d like to just cut that out

or… being lazy and just using

rootContext<MyClassUnderTest>

and doing everything else with fields which feels like an anti-pattern

I know what you mean. It’s there in xUnit, just part of the structure

while the Specs make use of oddly scoped locals

usually there’s a mixture of class-under-test, collaborators (often mocks), and dummy values (when they are shared across tests)

One thing that mitigates the fixture is that it is a place to put methods that make tests more expressive

yes

although I often do that with local extension methods as well

Indeed, but with the fixture as receiver, which makes them nicely reusable

I find it makes mocks less icky, because the fixture can have given methods that set up mocks

right, I’ve tended to do it with class-under-test or collaborator as the receiver but fixture would be good for anything that cuts across those

I’m certainly still learning the patterns that make sense

When we’ve settled on common ones we can express them as utilities