-
Notifications
You must be signed in to change notification settings - Fork 744
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
mock: differentiate between mocks and expectations #2373
Conversation
The `tracing-mock` crate provides a mock collector (and a subscriber for use by the tests in the `tracing-subscriber` crate) which is able to make assertions about what diagnostics are emitted. These assertions are defined by structs that match on events, span, and their fields and metadata. The structs that matched these objects have been called, up until now, mocks, however this terminology may be misleading, as the created objects don't mock anything. There were two different names for similar functionality with `only()` and `done()` on fields and collectors/subscribers respectively. Using a single name for these may make it easier to onboard onto `tracing-mock`. To reduce confusion, these structs have been split into two categories: mocks and expectations. Additionally, the `done()` function on the `Collector` and `Subscriber` mocks has been replaced with `only()`. This matches the similar function for `ExpectedField`, and may be more intuitive. The mocks replace some component in the tracing ecosystem when a library is under test. The expectations define the assertions we wish to make about traces received by the mocks. Mocks (per module): * collector - `MockCollector`, no change * subscriber - `MockSubscriber`, renamed from `ExpectSubscriber` Expectations (per module): * event - `ExpectedEvent`, renamed from `MockEvent` * span - `ExpectedSpan`, renamed from `MockSpan` * field - `ExpectedField` and `ExpectedFields`, renamed from `MockField` and `Expected`. Also `ExpectedValue` renamed from `MockValue`. * metadata - `ExpectedMetadata`, renamed from `Expected` Refs: #539
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good to me overall—I like the changes.
quick question about .only()
being used at the top, Collector level: is that only necessary to to ensure that that it's an exact match? if so, can that be elided entirely?
The I don't think I understand the question about eliding it complete though. |
The `tracing-mock` crate provides a mock collector (and a subscriber for use by the tests in the `tracing-subscriber` crate) which is able to make assertions about what diagnostics are emitted. These assertions are defined by structs that match on events, span, and their fields and metadata. The structs that matched these objects have been called, up until now, mocks, however this terminology may be misleading, as the created objects don't mock anything. There were two different names for similar functionality with `only()` and `done()` on fields and collectors/subscribers respectively. Using a single name for these may make it easier to onboard onto `tracing-mock`. To reduce confusion, these structs have been split into two categories: mocks and expectations. Additionally, the `done()` function on the `Collector` and `Subscriber` mocks has been replaced with `only()`. This matches the similar function for `ExpectedField`, and may be more intuitive. The mocks replace some component in the tracing ecosystem when a library is under test. The expectations define the assertions we wish to make about traces received by the mocks. Mocks (per module): * collector - `MockCollector`, no change * subscriber - `MockSubscriber`, renamed from `ExpectSubscriber` Expectations (per module): * event - `ExpectedEvent`, renamed from `MockEvent` * span - `ExpectedSpan`, renamed from `MockSpan` * field - `ExpectedField` and `ExpectedFields`, renamed from `MockField` and `Expected`. Also `ExpectedValue` renamed from `MockValue`. * metadata - `ExpectedMetadata`, renamed from `Expected` Refs: #539
The `tracing-mock` crate provides a mock collector (and a subscriber for use by the tests in the `tracing-subscriber` crate) which is able to make assertions about what diagnostics are emitted. These assertions are defined by structs that match on events, span, and their fields and metadata. The structs that matched these objects have been called, up until now, mocks, however this terminology may be misleading, as the created objects don't mock anything. There were two different names for similar functionality with `only()` and `done()` on fields and collectors/subscribers respectively. Using a single name for these may make it easier to onboard onto `tracing-mock`. To reduce confusion, these structs have been split into two categories: mocks and expectations. Additionally, the `done()` function on the `Collector` and `Subscriber` mocks has been replaced with `only()`. This matches the similar function for `ExpectedField`, and may be more intuitive. The mocks replace some component in the tracing ecosystem when a library is under test. The expectations define the assertions we wish to make about traces received by the mocks. Mocks (per module): * collector - `MockCollector`, no change * subscriber - `MockSubscriber`, renamed from `ExpectSubscriber` Expectations (per module): * event - `ExpectedEvent`, renamed from `MockEvent` * span - `ExpectedSpan`, renamed from `MockSpan` * field - `ExpectedField` and `ExpectedFields`, renamed from `MockField` and `Expected`. Also `ExpectedValue` renamed from `MockValue`. * metadata - `ExpectedMetadata`, renamed from `Expected` Refs: #539
The `tracing-mock` crate provides a mock collector (and a subscriber for use by the tests in the `tracing-subscriber` crate) which is able to make assertions about what diagnostics are emitted. These assertions are defined by structs that match on events, span, and their fields and metadata. The structs that matched these objects have been called, up until now, mocks, however this terminology may be misleading, as the created objects don't mock anything. There were two different names for similar functionality with `only()` and `done()` on fields and collectors/subscribers respectively. Using a single name for these may make it easier to onboard onto `tracing-mock`. To reduce confusion, these structs have been split into two categories: mocks and expectations. Additionally, the `done()` function on the `Collector` and `Subscriber` mocks has been replaced with `only()`. This matches the similar function for `ExpectedField`, and may be more intuitive. The mocks replace some component in the tracing ecosystem when a library is under test. The expectations define the assertions we wish to make about traces received by the mocks. Mocks (per module): * collector - `MockCollector`, no change * subscriber - `MockSubscriber`, renamed from `ExpectSubscriber` Expectations (per module): * event - `ExpectedEvent`, renamed from `MockEvent` * span - `ExpectedSpan`, renamed from `MockSpan` * field - `ExpectedField` and `ExpectedFields`, renamed from `MockField` and `Expected`. Also `ExpectedValue` renamed from `MockValue`. * metadata - `ExpectedMetadata`, renamed from `Expected` Refs: tokio-rs#539
Motivation
The
tracing-mock
crate provides a mock collector (and a subscriber foruse by the tests in the
tracing-subscriber
crate) which is able tomake assertions about what diagnostics are emitted.
These assertions are defined by structs that match on events, span, and
their fields and metadata. The structs that matched these objects have
been called, up until now, mocks, however this terminology may be
misleading, as the created objects don't mock anything.
There were two different names for similar functionality with
only()
and
done()
on fields and collectors/subscribers respectively. Using asingle name for these may make it easier to onboard onto
tracing-mock
.Solution
To reduce confusion, these structs have been split into two categories:
mocks and expectations.
Additionally, the
done()
function on theCollector
andSubscriber
mocks has been replaced with
only()
. This matches the similar functionfor
ExpectedField
, and may be more intuitive.The mocks replace some component in the tracing ecosystem when a library
is under test. The expectations define the assertions we wish to make
about traces received by the mocks.
Mocks (per module):
MockCollector
, no changeMockSubscriber
, renamed fromExpectSubscriber
Expectations (per module):
ExpectedEvent
, renamed fromMockEvent
ExpectedSpan
, renamed fromMockSpan
ExpectedField
andExpectedFields
, renamed fromMockField
and
Expected
. AlsoExpectedValue
renamed fromMockValue
.ExpectedMetadata
, renamed fromExpected
Refs: #539