Open steveklabnik opened 9 years ago
1000x this.
Interfaces having tests? It's a genius idea and if I implement Write and the Write trait tests pass my impl I would feel reasonably safe. We have an N x M problem of testing all impls meet all their interface obligations. Being able to have 'official' Trait tests would be a revolution in testing. If there's a framework for making this easy then people will do it - exhibit 1: xUnit.
I also agree that one would want to be able to not run the tests for an impl, but would be great to do something like:
pub struct Ident(String);
Though in the above there might be some tests one would like to run for anything Eq + Hash, rather than just single traits.
In 2013 when this was first suggested it might have been too soon, but the time is now, the world is ripe for this to happen. We have all the source code for the tests shipped with each crate, which is the first step down this road.
Has anyone done / seen any crates trialing out some ideas on how this might work?
We have procedural macros, so all this can be implemented in an external crate.
On Mar 11, 2018 8:19 PM, "Squirrel" notifications@github.com wrote:
1000x this.
Interfaces having tests? It's a genius idea and if I implement Write and the Write trait tests pass my impl I would feel reasonably safe. We have an N x M problem of testing all impls meet all their interface obligations. Being able to have 'official' Trait tests would be a revolution in testing. If there's a framework for making this easy then people will do it - exhibit 1: xUnit.
I also agree that one would want to be able to not run the tests for an impl, but would be great to do something like:
[derive(Debug, Clone, Eq, Hash)]
[autotest(Debug, Clone, Eq, Hash)]
pub struct Ident(String);
Though in the above there might be some tests one would like to run for anything Eq + Hash, rather than just single traits.
In 2013 when this was first suggested it might have been too soon, but the time is now, the world is ripe for this to happen. We have all the source code for the tests shipped with each crate, which is the first step down this road.
Has anyone done / seen any crates trialing out some ideas on how this might work?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rust-lang/rfcs/issues/616#issuecomment-372136562, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0kjJULQajljzBIQHNJrDrMa6IeHmks5tdWqtgaJpZM4DU_tf .
I’ve got some examples of trait tests up and running at https://github.com/gilescope/iunit
(It requires a compiler plug-in at the moment - http://github.com/gilescope/trait_tests )
trait Bar { static fn zero() -> Self; fn neg(&self) -> Self; #[test] fn test_bar() { let x: Self = zero(); let y = x.neg(); assert x == y; } }
I just released a crate tested-trait
that enables this style of testing traits. Examples and details in the docs and announcement.
I didn't know about this RFC and trait_tests
until after writing tested-trait
. tested-trait
is similar to trait_tests
, but has a design I think is more ergonomic and robust. I wrote a brief comparison here.
Nice job! Being able to add where clauses to the individual tests gives it a lot of flexibility. Can one add multiple test_impl attributes if you want to test it for several concrete implications?
Nice job! Being able to add where clauses to the individual tests gives it a lot of flexibility. Can one add multiple test_impl attributes if you want to test it for several concrete implications?
Thanks! To test multiple concrete implementation you can pass a list to test_impl
— see here
Issue by Kimundi Monday Feb 04, 2013 at 12:53 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/4782
This issue was labelled with: A-an-interesting-project, A-testsuite, A-traits, I-wishlist in the Rust repository
After an discussion about how for example
0 == -0
, and how it interacts with traits, I had the thought it might be nice to have unit tests on traits that get generated for for eachimpl
of it. 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: