LukasKalbertodt
Collaboration with t-testing-devex
My personal goal is first-class custom test harnesses with a de facto harness that offers the flexibility of pytest which would make it so I no longer need libtest-mimic (unsure if there would still be a case for others). See my blog post for more background.
T-testing-devex has not yet officially adopted that goal but we are experimenting with a custom test harness as a playground for json output to work towards stabilizing it. After that, I expect us to officially adopt a goal for first-class custom test harnesses which would apply lessons from our custom test harness and allow us to test out unstable features with it. I'd like us then to also officially adopt this work.
So with that context out of the way.
One of my first milestones in this effort was to create a "libtest-mimic2".
What I'm hoping for:
- Any feedback
- Thoughts on whether you would want this eventually moved into
libtest-mimicand what would you like to see before doing so (including API stability, quality, etc) - If that is far enough out, any concerns with my publishing a "libtest-mimic2" for early adopters to provide feedback on its usage and if you have feedback on names (e.g. to avoid confusion). Potentially, I could also use versions
0.0.x.
Hi and thanks for my slow reply! It's great to see there are some developments in this area. I agree, ideally there is no need for libtest-mimic in the Rust ecosystem.
The past few years, I've been generally terrible at maintaining this library (as you surely have noticed by the response time...). The main reason is simply: I'm not using it anymore for any of my projects and I have no particular interest in the area anymore. So I also don't really have qualified input on the new crate's API design.
I'm not exactly sure how your path forward looks like, but let me just state that I'm not opposed to moving control/ownership of libtest-mimic if that benefits the wider community. But again, I didn't really have the time to dig through t-test-devex docs and such, so I hardly know anything about current developments.
If you want, I can take over maintenance under the https://github.com/assert-rs/ org which is where we are housing libtest2 work. libtest2-mimic provides a smaller test case for our overall strategy until we get to the point that libtest2 can cover all of the use cases and has a first class experience which likely won't be for quite a while.
My plan would for maintaining this would be to adapt libtest2-mimic to cover libtest-mimics use cases and drop the 2 from the name. As I'm pushing for as wide adoption as possible for libtest2, fast compile times and a low MSRV are my top priorities which extend to libtest2-mimic. I would likely deem major extensions out of scope, like #51, pointing instead to libtest2.