Let's say I wanted to run something other than Rust unit tests...

[zmitchell]

Hey Rain! So I've got this crazy idea of taking a fork of cargo-nextest and making it run some shell scripts instead of Rust unit tests (context: we use bats in anger, currently).

I see this discussion is related, but I'm not super concerned with the "it may be a lot of work" part because this is half experiment, half "just crazy enough it might work", and if it looks like less work to just write from the ground up, that's fine too, I'll be cribbing from nextest's signal handling anyway.

On the surface it seems like the there are lots of similarities between what nextest can currently do and what I would need:

• Collect tests (this would be different for me, I'm working on my own file format and parser).
• Spawn processes (cmd = <shell> <path to generated script> in my case) for each test.
• Monitor process status during execution.
• Record metrics on execution time, etc.
• Check exit codes to determine pass/fail.
• Format a final report (including JUnit XML).

So, that's the basic idea. In order to assess how much work this looks like, do you have any quick recommendations for which modules I'd be ripping out, which ones could be entirely re-used, or stuff like that?

[sunshowers]

Thanks for the question! I think the main thing that you'd have to write yourself is the bit that collects tests from binaries, and the code that executes individual tests. The rest can hopefully be reused.

I've been really hesitant to make any of this generic without a second use case at hand -- the interface is quite complex and it's easy to design it badly. But I'm open to accepting refactors to make your life easier. (Nextest supporting doctests may also act as a forcing function.)