Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Generated tests for trait impls #4782
After an discussion about how for example
in some other crate:
Then a rustc --test for that crate would generate this function:
This would require trait test to somehow be made publicly callable from other crates for test compilation.
Alternative example, which might be easier to implement:
Triage: I like, but no progress.
(It seems like this would need some adjustments for more generic traits that don't have a constructor built-in (i.e.
I think this would make more sense to be an opt-in feature for an implementer. Not necessarily "All implementers of this trait should pass these tests" but "if you implement this trait, here are some great pre-made tests to save you some time". That way we don't have everyone who implements a MutableMap copy-pasting the same insert/remove/len boilerplate. If a structure is simple enough, it could literally see it just doing:
It should also permit some tests to only be run if other traits are present, as I think we expect a lot of orthogonal traits to be together and interact predictably. For instance it's not a stretch to say that most MutableMaps are going to implement Default and Collection, and so if an impl does, we can provide tests that confirm construction and length and mutation all interact the way we'd expect.
So something like:
produces all applicable tests. Of course we could have no syntax at all, and just have modules of "good common tests" supplied with traits that implementers manually use. At very least I think that's easy and desirable. I vaguely recall seeing some structure pull in some testing utilities from Deque, though I can't for the life of me find it now. We should have more of that. Any way to increase test reuse.
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.
This issue has been moved to the RFCs repo: rust-lang/rfcs#616