integration tests' dependencies do not have a dedicated manifest section

[tamird]

Problem

integration tests are a useful concept, but in cases where additional test-only 3rd party crates are needed, they are unusable because they don't get to use dev-dependencies and do not have their own dependency section in the manifest.

Proposed Solution

The simplest solution would be to link dev-dependencies into integration tests.

Notes

No response

[epage]

Could you provide an example scenario? I'm not too sure what the problem is you are trying to highlight.

[tamird]

When I write some unit tests, and I want to use test-only dependencies such as pretty_assertions, the documentation suggests using dev-dependencies.

Now suppose I want to write an integration test that uses pretty_assertions - where do I declare that my test needs that crate? As I write in the issue description: integration tests are compiled without dev-dependencies, and it would be inappropriate to add pretty_assertions to my crate's dependencies.

[epage]

s I write in the issue description: integration tests are compiled without dev-dependencies

They should be compiled with dev-dependencies. Do you have a reproduction case?

[tamird]

I was attempting to reproduce this by writing a test in the cargo repo, but you are right - they seem to be getting the dev-dependencies. This was PEBKAC.

[tamird]

The actual issue was that dev-dependencies are linked to both unit and integration tests, which can create poor interactions with the unused-crate-dependencies lint.

It would be good to have a separate section in the manifest for the dependencies of integration tests for this reason.

[epage]

dev-dependencies are for all development tasks including

• unit tests
• integration tests
• examples

I'm assuming the unused-crate-dependencies lint won't just trigger if a dependency isn't used among any integration test but will trigger on each integration test that doesn't use that dependency. This means we'd need per-build-target dependencies. At that point, this is a duplicate of #1982.

[tamird]

Not only that, it will also trigger on the main crate if the dev-dependency isn't used in any unit tests.

[epage]

Is there any reason we shouldn't close in favor of #1982?

[tamird]

Seems reasonable to do so.