Slightly too off-topic for #304

[NyxCode]

@escritorio-gustavo
Regarding this comment of mine:

I suspect that's true. For something like example/, I think we could make it work with a static holding the current state, but as soon as there are multiple test executables, like in the ts-rs test suite, stuff get's very complicated.

When attempting to do this without the CLI, statics are pretty useless as soon as there are multiple test executables.
So the only valid alternative to keep state is the filesystem. Here's how a test would need to look like:

The big question here is how to implement the red square, "is this the first test to run?".

For one, that question only makes sense when running just cargo test. Users could, of course, just run the test executables manually.

Besides that, I'm not sure how I'd even attempt to answer the question "is this the first test to run?". Maybe by having each #[test] append std::env::current_exe() to the metadata file, and comparing the paths of the executables in the metadata file with what's present under target/?

So yeah, this get's suuper complicated and messy, unless I'm missing something here.

[escritorio-gustavo]

I agree, the way Rust tests are run in parallel and with multiple executables makes it very difficult to get the information we need

Besides that, I'm not sure how I'd even attempt to answer the question "is this the first test to run?". Maybe by having each #[test] append std::env::current_exe() to the metadata file

This could (if we don't get a lot of race conditions) tell us whether or not the current test executable is the first one to run, but we still can tell whether the current test inside that executable is the first to run

[NyxCode]

Right, but that's the far easier problem to solve with a static METADATA_FILE: Mutex<Option<File>>.
Definetely a fun thought experiment. Seems like doing this in tests only isn't as completely impossible as I imagined, but I wouldn't be comfortable shipping something that hacky ^^

[escritorio-gustavo]

Right, but that's the far easier problem to solve with a static METADATA_FILE: Mutex<Option<File>>.

Oh, yeah, I totally forgot about the static mutex thing lol

Seems like doing this in tests only isn't as completely impossible as I imagined

If there is a will, there is a way 😆

I wouldn't be comfortable shipping something that hacky ^^

Agreed, I think the whole point of building a CLI is to avoid having so many hacks