Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract test framework #793

Closed
wants to merge 11 commits into from

Conversation

GeorgeHahn
Copy link

Motivation

A published crate with mocks for common tracing types will benefit the greater tracing ecosystem.

Solution

Extract the existing mocks into a separate crate. I did some minor refactoring to (hopefully) improve clarity and decrease verbosity. These are in standalone commits to make it easy to pick and choose changes. (The exceptions are fixup commits, which should be dropped if the previous commit(s) are dropped.)

I'm not sure if no-std is useful for this and I didn't test it, but I left the scaffolding in place for it.

From issue #539

@GeorgeHahn GeorgeHahn requested review from hawkw and a team as code owners July 10, 2020 02:20
@GeorgeHahn GeorgeHahn force-pushed the extract-test-framework branch 2 times, most recently from ae68425 to 8cd5450 Compare July 10, 2020 02:43
@GeorgeHahn GeorgeHahn force-pushed the extract-test-framework branch from 8cd5450 to 9738aef Compare July 10, 2020 02:57
@GeorgeHahn
Copy link
Author

Sorry for the force pushes, I had a couple of small errors to fix and wanted to preserve the single commit per refactoring. I won't rebase future changes.

@hawkw
Copy link
Member

hawkw commented Jul 10, 2020

@GeorgeHahn don't worry about it, that's fine!

Copy link
Member

@davidbarsky davidbarsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really have that much feedback given that these changes were largely mechanical, so if my concerns are addressed I'm happy to get this merged.

I also hope that you used some automated refactoring tools instead of doing all this by hand!

tracing-test/src/lib.rs Outdated Show resolved Hide resolved
Comment on lines 17 to 21
//! ```rust
//! # fn docs() {
//! // TODO
//! # }
//! ```
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add an end-to-end example of something like the event_with_message test in tracing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. I added a span to show the enter/exit/drop sequence, but I'm not sure if it's useful enough to justify the added lines. What do you think?

tracing-attributes/tests/fields.rs Outdated Show resolved Hide resolved
@GeorgeHahn
Copy link
Author

Thanks for the review! Sorry it took so long for me to revisit this.

I also hope that you used some automated refactoring tools instead of doing all this by hand!

Fortunately yes! 😄 This was mostly done with regexes, though rust-analyzer is at the point where it could have handled a lot of these changes too.

@hawkw
Copy link
Member

hawkw commented Aug 12, 2020

We should update this branch to integrate the changes to the mock subscribers from PR #908 (adding support for testing with the max level hint). Also, PR #919 will make additional changes to the mock subscribers, so we'll want to integrate that as well.

Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, and I'm sorry it took me so long to look at it.

Overall, it looks good. I left a few comments, most of which are non-blocking nits. The only issue that I think needs to be addressed before this PR merges is the conditional no-std support, which I don't think will actually work as expected. We should either fix it or remove it.

@@ -0,0 +1,43 @@
# tracing-test

Testing utilities for the tracing ecosystem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: since the README is rendered for the crate's description page on crates.io, I usually like to make sure there is a link back to tracing's crates.io page somewhere near the top.

@@ -0,0 +1,66 @@
//! Testing utilities for `tracing`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: similarly, nice to link to tracing on docs.rs here.

},
}
}
pub fn new() -> MockSpan {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about naming this something like any? Then, the test DSL would look like this:

span::any()
   .at_level(...)
   .with_field(...)

Comment on lines +25 to 32
event().with_fields(
field("answer")
.with_value(&42)
.and(
field::mock("to_question")
field("to_question")
.with_value(&"life, the universe, and everything"),
)
.only(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be worth reworking this API a bit to reduce the rightward drift from multiple fields, like

event()
   .with_field(field("answer").with_value(&42))
   .with_field(field('to_question").with_value(&"life, the universe, and everything"))
   .only()

but, that would be more than a simple mechanical change, so take it or leave it.

We could also do this in a follow-up PR, but we'd want to make the change before releasing the crate, because it would be a breaking change.

//!
//! `tracing-test` offers mock implementations of `tracing` types such as Spans, Events,
//! and Subscribers. These mocks are intended to be used in testing `tracing`-based crates.
//!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make sure the stability note is present in the lib.rs docs as well.

`tracing-test` provides testing utilities that are used internally in the
`tracing` codebase and may be useful elsewhere in the `tracing` ecosystem.

This crate is unstable and does not make any stability guarantees.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should guarantee that we will follow semver when breaking the test support code, but not that we won't churn versions rapidly.


## License

This project is licensed under the [MIT license](LICENSE).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's also add a copy of the MIT license in the tracing-test dir. Since cargo publish is run in that directory, it will only include a copy of the license if we add one there (see #842).

//! handle.assert_finished();
//! # }
//! ```
#![cfg_attr(not(feature = "std"), no_std)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it matters all that much to have no-std support for this crate...in most cases, I think tests are run with std even in projects that are otherwise no-std, with

#[cfg(test)]
extern crate std;

or similar.

On the other hand, I don't think we use any std APIs that aren't in alloc, so we could support no-std. However, I think we should make sure that this actually builds without std, before publishing it with no-std.

For example, I think that the import paths for the std APIs we use won't work, since they might be coming from core/alloc. If we want the test support code to support no-std, we need to do something like what tracing and tracing-core do: create a module that conditionally re-exports from either std or core/alloc and ensure it's used everywhere instead of std.

@mihai-dinculescu
Copy link

Any update on this? Would love to see it merged :)

@GeorgeHahn
Copy link
Author

GeorgeHahn commented Oct 3, 2020 via email

@GeorgeHahn
Copy link
Author

Closing this because it's quite stale.

@GeorgeHahn GeorgeHahn closed this May 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants