tracing

tracing copied to clipboard

Feature Request

Motivation

I'm writing a 3rd party library for instrumenting programs with tracing spans https://github.com/yaahc/spandoc that I would like to be able to test using the tracing test framework without having to vendor the test framework or write my own test subscriber.

Proposal

Publish the contents of tracing/tracing/tests/support and any other necessary machinery so that they can be added as a dev dependency to spandoc and tests can be created that verify span entry and exit ordering.

It is not necessary for the tracing crates themselves to depend on the published version via crates.io. Eliza has some worries about introducing a need to maintain API stability into the test framework, not depending on the published version should make this a less important concern, its okay if the published version drifts from the actively used version by the main tracing crates so long as the core functionality that is published to crates.io still works.

Alternatives

Alternatively I can just vendor support files into my crate and depend on them in the same way that tracing crates do.

Hmm, if we're going to do this, I think the test framework needs a lot of cleanup. At the very least, we should:

• [ ] ensure that the panic output is readable and is actually formatted nicely
• [ ] ensure there are no double panics/panics in drop
• [ ] try to make the test dsl less verbose (e.g. turn span::mock().named("foo") into just span("foo") or something
• [ ] make the naming make more sense
• [ ] add API docs

i notice that the actix-tracing integration crate that was recently published has basically reproduced its own version of the test support code as well: https://github.com/actix/actix-net/blob/aed5fecc8a0b994cc871483bcf15b3c5fbb350df/actix-tracing/src/lib.rs#L139-L225

so, perhaps that's more evidence in support of making it publicly available...

Hayden's list of things to do before publishing:

• [ ] Add README - should be tested
• [ ] Add documentation to all public APIs, including examples / doctests to most of them
• [ ] Add #[must_use] to the public API where necessary
• [ ] Add expectation for Collector::try_drop to MockCollector
• [ ] Add negative tests for all assertions (as in, we should test that tracing-mock will correctly fail a test if the code under test is wrong) - this should also test that there are no double panics
• [ ] Improve the logging output of the tests - it can be very verbose
• [ ] Improve the panic output so that it's readable and nicely formatted

Hi, @hds, I can see you're made quite a progress on this, is there anything to help out with regarding this?

I've tried using this recently (through git dependency) and from the lists I've seen here, the double panics happened to me a few times and the output might be improved but other than that, do you think there is more work to be done?

@mladedav I've got a couple of necessary refactorings pending and then one or two more PRs to complete the documentation. Some of the changes that have made it into master also need to be backported I think (although I'm not 100% sure of the state of that).

I must admit, that I haven't looked into the double panics yet, so if you have specific reproductions then that would be really useful. If you could open an Issue with the repo and let me know, I can have a look.