-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Generated tests for trait impls #616
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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)] 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" ***@***.***> 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
<#616 (comment)>, 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 ) |
I just released a crate I didn't know about this RFC and |
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 |
Monday Feb 04, 2013 at 12:53 GMT
For earlier discussion, see rust-lang/rust#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:
The text was updated successfully, but these errors were encountered: