I found this old post here that mentions how to access src/*.rs from your integration tests: Multiple binaries in cargo - #4 by SpeckledSea
But when I try, I get "can't find crate for 'my_app'. What am I doing wrong?
Would you mind sharing a minimal reproducible example of your setup? I assume your library crate is not named my_app, but without knowing your project structure and the contents of your Cargo.toml file, we can only guess at what your problem is.
Most likely you do not have any library crate (that is, no src/lib.rs). The two things that integration tests are specifically provided access to are:
- The package’s library target, if it has one, is available for use just like any other library dependency.
- The package’s binaries are built and their paths are passed to the test via environment variables.
But you cannot refer to items from the binaries as if they were libraries.
No library; it's just a binary. Specifically it's an embassy stm32 embedded system.
Then why did that old forum quote say you could?
Can I modify the cargo defaults and specifically request that the src directory be searched when a test mentions a mod?
Quoting the linked post:
Binary module is not "publicly exported". Only library modules are.
If it says pub on it then it's publicly exported no?
It seems to just be a problem with the way the linker is invoked.. how to get cargo to build and link the other files?
How about with a multi-binary project? Do you really have to put 95% of your code into a lib and then have each binary just be a thin wrapper around the lib? That seems silly.
To offer another perspective, if everything is in lib then a subsequent project can include your crate and invoke almost all the utilities you wrote, in a way they need; say, to supply config from a variable and not from a file.
I know what a library is, and this isn't one. It is a highly specialized embedded system. It isn't going to be reused. But it does need unit testing.
Yes, obviously.
Why exactly? You propose to create a lot of kludges to make it possible to use binaries as libraries… what would that achieve? Somone on the forum would stop saying “it's silly”? Why is that a good enough justification?
Not just that. On some platforms libraries and binaries use the same format, on some platforms they use different formats. On same platforms linker could import symbols from libraries, on some platforms that's not possible.
The simplest way not to dig through all that mess is just to assume binaries are binaries, not “binaries that can also be used as libraries”, where it's possible.
Then could you use facilities Rust offers for unit testing, that is, #[test] functions inside the tested module itself?
2 Likes