Code organisation - test fixtures for unit & integration tests

help
1

Are there any good, idiomatic, approaches out there to organising test fixtures which need to be used in both unit & integration tests?

I currently have:

src
| ...
| - test_fixtures
|   | - mod.rs
|   - - albums.rs            # hard coded expected results & asset loaders
tests
| - assets                   # stuff that needs network or hardware access
|   | - definitely_maybe
|   |   | - TOC.hex
|   |   | - musicbrainz.json
|   |   | ...
...

Cargo.toml

...
[features]
# for integration testing - expected results correlating to tests/assets
test_fixtures = ["dep:serde_json"]
...

But this requires me to always run cargo test --all-features

If I try using #[path(...)]in the integration tests as suggested a few years ago. I still run into the issue that my fixtures are either part of the default library code, or feature-gated and tests need all-features. [edit: plus I get issues with import crate::something_pub_crate; in my fixtures]

Thanks in advance

2

A more idiomatic option would be to turn test_fixtures into its own library, importing it as a dev-dependency:

3

Thanks - I now notice that's why I haven't had this issue before(!). I'd just flattened this out into a single crate from a mixed-bag workspace so didn't even consider "going back"...

(For future readers: if you need a fixture for testing proc_macros do what they should - a separate crate is the way to do it too)