Cargo: how do I make a integration test A depend on binary B?

#1

I’ve got a rust project that currently consists of a single [[bin]] target (but that could trivially be split up into a bin and a lib - main.rs does some trivial initialization and then calls a single method in a sub-module).

I’m about to write some code that will involve running a sub-process. The easiest way I can think of to test this is to create a binary that just writes its command-line args and working directory to a temp file. The test can then make the code that should run the sub-process, then check that the output file was created and contains the expected args and working directory.

The problem is how do I tell Cargo “before you run the tests in module A, make sure that you’ve built binary B”. Any suggestions?

Thanks

Mark

Ideas for writing portable tests executing external programs?
#2

This should just work. When running integration tests, Cargo makes sure that binaries are build. In fact, Cargo itself uses this to test itself :slight_smile:

#3

Cool. That makes things easy :slight_smile:
thanks

Mark

#4

Alas that doesn’t seem to work :-(. My cargo toml has this:

[[bin]]
name = "find"
path = "src/find/main.rs"

[[bin]]
name = "testing-commandline"
path = "src/testing/commandline/main.rs"

and src/find/mod.rs has tests that expect ./target/debug/testing-commandline to exist.

If I run cargo build; cargo test then everything works fine. If I run cargo clean; cargo test then my tests fail because testing-commandline doesn’t exist. What am I doing wrong?

#5

I think you need to put your integration style tests at src/tests/foo.

When running unit tests, cargo won’t build binaries. You also probably don’t want to hard-code debug in the path. See how Cargo handles this: https://github.com/rust-lang/cargo/blob/19fdb308cdbb25faf4f1e25a71351d8d603fa447/tests/cargotest/support/mod.rs#L308

#6

Doh! I’m an idiot. thanks.

I hadn’t actually hard-coded debug (that was a simplification in my mail), but I was using the env::args().next(). env::current_exe is neater :slight_smile: thanks for the tip

Mark