Skip to content
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

Generated tests for trait impls #616

Open
steveklabnik opened this issue Jan 21, 2015 · 7 comments
Open

Generated tests for trait impls #616

steveklabnik opened this issue Jan 21, 2015 · 7 comments
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.

Comments

@steveklabnik
Copy link
Member

Issue by Kimundi
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 each impl of it.
Example:

trait Bar {
    static fn zero() -> Self;
    fn neg(&self) -> Self;
}

#[test(trait)]
fn test_bar<T: Bar>() {
    let x: T = Bar::zero();
    let y = x.neg();
    assert x == y;
}

in some other crate:

impl Bar for float {
    static fn zero() -> float { 0.0 }
    fn neg(&self) -> float { - *self }
}

Then a rustc --test for that crate would generate this function:

#[test]
fn test_bar_float() { test_bar::<float>() }

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:

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;
    }
}
@petrochenkov petrochenkov added T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. T-dev-tools labels Jan 19, 2018
@gilescope
Copy link

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?

@nagisa
Copy link
Member

nagisa commented Mar 12, 2018 via email

@burdges
Copy link

burdges commented Mar 13, 2018

@gilescope
Copy link

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 )

@max-heller
Copy link

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.

@gilescope
Copy link

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?

@max-heller
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

6 participants