Tarpaulin: Compatibility with cargo test flags

Created on 3 Sep 2019  路  9Comments  路  Source: xd009642/tarpaulin

It would be good if tarpaulin could achieve parity with the cargo test flags. In particular the following come to mind:

  • --lib
  • --bin <NAME> and --bins
  • --example <NAME> and --example
  • --test <NAME> and --tests
  • --bench <NAME> and --benches
  • --doc
  • and most importantly: --features <NAME>

though there are many other flags that cargo test has but tarpaulin does not.

  • [x] --quiet - this is the default behaviour flag probably not needed
  • [x] --lib
  • [x] --bin <NAME> ...
  • [x] --bins
  • [x] --example <NAME>...
  • [x] --examples
  • [x] --test <NAME>...
  • [x] --tests
  • [x] --bench <NAME>...
  • [x] --benches
  • [x] --all-targets
  • [x] --doc
  • [x] --no-run
  • [x] --no-fail-fast (have a feeling this is a default for coverage)
  • [x] -p --package <SPEC>... (--packages in tarpaulin though rename)
  • [x] --all (did it pre-deprecation)
  • [x] --workspace (need to add as an alias)
  • [x] --exclude
  • [x] --release
  • [x] --profile
  • [x] --features
  • [x] --all-features
  • [x] --no-default-features
  • [x] --target (no point only support x64 linux currently and need to run it)
  • [x] --target-dir
  • [x] --manifest-path
  • [x] --verbose
  • [x] --color not implementing impacts aesthetics of tarpaulins printouts
  • [x] --frozen
  • [x] --locked
  • [x] --offline
  • [x] -Z
  • [x] -h --help
  • [x] -- ARGS ...

Most helpful comment

Bit more work done on this via a PR by @mathstuf and me adding --target-dir.

Decided to edit your comment to put a list of all the ones in cargo test just so the progress is visible from the main issue board :+1:

All 9 comments

You can pass arguments to the test executable by doing -- <test args> I don't know if that resolves any of those flags or not. But I'll go through year and add flags accordingly this weekend

Oh, I misread the documentation then. I thought that cargo tarpaulin -- <args> was used in the same way as cargo test -- <args> whereby the arguments go to the test binary. Still, it would be nice to generally have most flags from cargo test be supported by cargo tarpaulin so that one can easily run tests and then run code coverage.

By test executable I meant test binary I was just saying I didn't know if there was an overlap with any of the cargo test args and arguments you can pass into the test binary

So just to clarify: I think it would be nice if cargo test <args1> -- <args2> could be replaced by cargo tarpaulin <args1> -- <args2> in every case (unless there are certain cases which don't make sense). This would mean that the args for cargo test should be a subset of the args for cargo tarpaulin.

I don't know how tarpaulin actually works behind the scene. If cargo tarpaulin acts like a wrapper around cargo test, then this should be fairly straightforward to implement (though I don't really have time right now to do this).

Agreed. Being able to pass --no-run to split out build failures from test failures by step in CI would be great.

I've just added a --no-run. Also tarpaulin doesn't really act as a wrapper round cargo test it just uses a lot of the same cargo internals. I was initially going to do it around cargo test but the public API didn't expose enough and I didn't want to rely on std::process::Command internally

Bit more work done on this via a PR by @mathstuf and me adding --target-dir.

Decided to edit your comment to put a list of all the ones in cargo test just so the progress is visible from the main issue board :+1:

Just updated the checklist with some new options that are in the new release

Well as of today all the flags are implemented and in the develop branch! And you'll see them in the next release (unless of course you live on the edge).

Was this page helpful?
0 / 5 - 0 ratings