Semantic errors ignored in tests with cargo check --tests and cargo build --tests

[tbourvon]

Cargo version: cargo 0.19.0-nightly (fa7584c14 2017-04-26)

cargo check --tests and cargo build --tests seem to ignore semantic errors in tests.

I don't know if that's intentional, but it's frustrating to be unable to cargo check code in my tests properly.

Examples:

Common Cargo.toml

[package]
name = "check_test"
version = "0.1.0"
authors = ["me"]

[dependencies]

---

• src/lib.rs example 1

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        asset_eq!(1, 1); // intentional typo (semantic error)
    }
}

What happens: running cargo check --lib --tests completes with no errors (code 0)

What should happen: running cargo check --lib --tests should indicate:

cannot find macro `asset_eq!` in this scope
  help: did you mean `assert_eq!`?

---

• src/lib.rs example 2

fn not_a_test() {
    asset_eq!(1, 1); // intentional typo (semantic error)
}

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        
    }
}

What happens AND should happen: running cargo check --lib --tests indicates:

cannot find macro `asset_eq!` in this scope
  help: did you mean `assert_eq!`?

---

• src/lib.rs example 3

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        i'm syntaxically incorrect code
    }
}

What happens AND should happen: running cargo check --lib --tests (actually cargo check gives the same output, so I think that syntax is checked regardless of cargo filters) indicates:

message: 'expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `'m`
  label: expected one of 8 possible tokens here'

[alexcrichton]

Thanks for the report! This is actually expected, albeit somewhat odd, behavior. What's happening here is that we're actually never compiling the library in test mode! Specifically when you pass --tests that actually only includes integration tests right now (e.g. tests/*.rs) not the library tests as well. Additionally the --lib flag means "the compiled library", not "the tested library".

I think there's two possible fixes to this issue:

• Like cargo rustc, we could add a --profile flag to check. This means that to check the library you'd execute cargo check --profile test --lib
• We could also just add the library's tests to the --tests flag.

I'd personally be in favor of the latter, it seems to be the most reasonable! This is actually I think a relatively easy issue to tackle, would you be interested in sending a PR? I could help guide you through where the code is located and how to write a test!

[tbourvon]

@alexcrichton Thank you for your answer.

Actually, I would be thrilled to work on this issue, and I agree with you on the second option. Is there a way I can contact you so that we can talk about that?

[alexcrichton]

Oh awesome! We can either coordinate here or I'm also on IRC in #cargo on irc.mozilla.org as acrichto, either way is fine by me!

[carols10cents]

Related PR: #4039

[ehuss]

This is fixed by #4592. --tests now does all tests, including unit tests. Also, cargo check now has a --profile flag that can be used to target unit tests individually, such as cargo check --lib --profile test.