Tracking coverage on crates outside the currently executing workspace

[Nemo157]

In some situations it's necessary to have tests defined in a different workspace to the library. Currently afaict there is no way to record the coverage data from these tests.

Here's an example setup:

├── Cargo.toml
├── foo-tests/
│   ├── Cargo.toml
│   └── tests/
│       └── foo.rs
├── src/
│   └── lib.rs
└── tarpaulin.toml

# Cargo.toml
[package]
name = "foo"
version = "0.1.0"
edition = "2024"

# foo-tests/Cargo.toml
[package]
name = "foo-tests"
version = "0.1.0"
edition = "2024"

[dependencies]
foo.path = ".."

// foo-tests/tests/foo.rs
#[test]
fn test() {
  foo::add(1, 2);
}

// src/lib.rs
pub fn add(left: u64, right: u64) -> u64 {
    left + right
}

# tarpaulin.toml
[tests]
manifest-path = "foo-tests/Cargo.toml"

Running coverage on it gives:

> cargo tarpaulin
...
2025-01-03T13:16:37.775101Z  INFO cargo_tarpaulin::process_handling: running target/x86_64-unknown-linux-gnu/debug/deps/foo-be23343dc3c96be8

running 1 test
test test ... ok

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

2025-01-03T13:16:37.932096Z  INFO cargo_tarpaulin::report: Coverage Results:
|| Uncovered Lines:
|| Tested/Total Lines:
||
NaN% coverage, 0/0 lines covered

The src/lib.rs coverage data isn't recorded because it fails this check:

tarpaulin/src/path_utils.rs

Line 64 in c493bc1

fn is_part_of_project(e: &Path, root: &Path) -> bool {

I think what is needed is the ability to have the root for the recorded coverage different to the root of the workspace used for resolving relative paths. (In the real project I ran into this on we have tests in both the root workspace and multiple sub-workspaces that we want to merge all together into one coverage report, with the majority of library code in the root workspace).

[xd009642]

A bit late to this but I was finishing off my holidays! I guess I'd always worked on the assumption that projects like that would make use of workspaces but this makes sense and is something tarpaulin should support.

Now I'm wondering if I can slightly extend the interaction of --manifest-path and --root so that if both are specified the root defines where all the files for coverage are found but --manifest-path works the same. Because right now if --manifest-path is set --root is ignored. Or maybe you have some other opinions on what would be a better UX 👀

EDIT: also playing around with some other ideas will update if I get anything good

[xd009642]

okay tarpaulin UX question (this is related). Right now if I do:

cargo tarpaulin --exclude-files src/ignore_me/*

It naturally ignores all the files in src/ignore_me/ but... It expects a path relative to the root directory not the current directory so if I do in a folder where lets say I run it in project root but there's a rust project inside that called foo:

cargo tarpaulin --root foo/Cargo.toml --exclude-files src/*

It'll ignore things in $PWD/foo/src/* not $PWD/src/* . Is this desirable or just confusing 🤔 . It's kinda an emergent over time behaviour naturally supporting every possible project layout and config people want leads to things interacting in ways I don't expect until I try them or someone raises an issue. My natural inclination is that doing things relative to the directory you run the command in is more sensible.

And here's the pay off on why it might be helpful here! If it worked like that then we could make use of the new --include-files arg to let you do:

cargo tarpaulin --manifest-path foo-tests/Cargo.toml --include-files src/*

Or I suppose I could also allow it to work with .. and add some extra logic to spot them and look for out of directory files as well in which case it would be:

cargo tarpaulin --manifest-path foo-tests/Cargo.toml --include-files ../src/*

The latter wouldn't be a breaking change so maybe less risky but surely if I do a blogpost and explicitly call it out in the release notes people won't have their pipelines broken 🫠