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

Binaries aren't compiled and problem with assert_cmd #903

Closed
cschwan opened this issue Dec 17, 2021 · 6 comments
Closed

Binaries aren't compiled and problem with assert_cmd #903

cschwan opened this issue Dec 17, 2021 · 6 comments
Assignees

Comments

@cschwan
Copy link

cschwan commented Dec 17, 2021

Describe the bug
Tarpaulin doesn't work together with assert_cmd, because tarpaulin doesn't build binaries (or deletes them). After working around the problem no line coverage is generated.

To Reproduce

cargo new mwe
cd mwe
echo 'assert_cmd = "2.0.2"' >> Cargo.toml
cat <<EOF >> src/main.rs

#[cfg(test)]
mod tests {
    use assert_cmd::Command;

    #[test]
    fn run_main() {
        Command::cargo_bin("mwe")
            .unwrap()
            .assert()
            .success();
    }
}
EOF
cargo build # needed to create the binary
cargo test # this works as expected
cargo tarpaulin --ignore-tests # this fails, see error below

The error:

Dec 17 16:30:02.461  INFO cargo_tarpaulin::config: Creating config
Dec 17 16:30:02.496  INFO cargo_tarpaulin: Running Tarpaulin
Dec 17 16:30:02.496  INFO cargo_tarpaulin: Building project
Dec 17 16:30:02.496  INFO cargo_tarpaulin::cargo: Cleaning project
   Compiling memchr v2.4.1
   Compiling libc v0.2.112
   Compiling either v1.6.1
   Compiling doc-comment v0.3.3
   Compiling predicates-core v1.0.2
   Compiling termtree v0.2.3
   Compiling lazy_static v1.4.0
   Compiling difflib v0.4.0
   Compiling regex-automata v0.1.10
   Compiling itertools v0.10.3
   Compiling predicates-tree v1.0.4
   Compiling bstr v0.2.17
   Compiling wait-timeout v0.2.0
   Compiling predicates v2.1.0
   Compiling assert_cmd v2.0.2
   Compiling mwe v0.1.0 (/tmp/mwe)
    Finished test [unoptimized + debuginfo] target(s) in 3.70s
Dec 17 16:30:06.277  INFO cargo_tarpaulin::process_handling::linux: Launching test
Dec 17 16:30:06.277  INFO cargo_tarpaulin::process_handling: running /tmp/mwe/target/debug/deps/mwe-517cb110a12ca1f1

running 1 test
test tests::run_main ... FAILED

failures:

---- tests::run_main stdout ----
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: CargoError { cause: Some(NotFoundError { path: "/tmp/mwe/target/debug/mwe" }) }', src/main.rs:12:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::run_main

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Error: "Test failed during run"

The problem is surely triggered because tarpaulin cleans the project. Using --skip-clean I can avoid this, but in that case I don't get line coverage. Is this expected? How do I get coverage for the main function?

@xd009642
Copy link
Owner

So to get coverage binaries actually have to be built with a specific set of linker flags. Also because -Clink-dead-code has frequently caused incremental compilation errors with rustc (and last I checked still does on certain platforms). Tarpaulin does clean by default. You also need --follow-exec to follow application spawns.

So what you want is probably something like cargo tarpaulin --run-types Bins Tests Lib --follow-exec. If that doesn't work maybe cargo tarpaulin --command Build --no-run && cargo tarpaulin --follow-exec --skip-clean

@cschwan
Copy link
Author

cschwan commented Dec 29, 2021

@xd009642 thanks a lot! Your second options works for me. You can close this Issue as far as it concerns me.

@xd009642
Copy link
Owner

Cool, also I came across this in a discussion the other day and found just a simple cargo tarpaulin --follow-exec worked for a project using assert_cmd that I made. So may be worth trying that as well! (Link to discussion: #908)

@cschwan
Copy link
Author

cschwan commented Dec 29, 2021

@xd009642 Only adding --follow-exec didn't work in my case, although the binary was built (somewhere) ... but it works for me

@danieleades
Copy link
Contributor

is this the same issue impacting cargo-msrv?

@cschwan
Copy link
Author

cschwan commented Jan 9, 2022

As far as I can tell no, it seems that your test simply runs longer than the timeout that you specified (line 510), I'd simply increase it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants