Instruments with names which are case-insensitive equal contribute to… #5701
Conversation
… same metric, advice is not part of instrument identity
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #5701 +/- ##
============================================
+ Coverage 91.25% 91.26% +0.01%
- Complexity 5032 5042 +10
============================================
Files 556 556
Lines 14861 14901 +40
Branches 1389 1394 +5
============================================
+ Hits 13562 13600 +38
- Misses 896 899 +3
+ Partials 403 402 -1
☔ View full report in Codecov by Sentry. |
| && this.getDescription().equals(that.getDescription()) | ||
| && this.getView().equals(that.getView()) | ||
| && this.getSourceInstrument().equals(that.getSourceInstrument()); | ||
| } |
There was a problem hiding this comment.
The aggregationName used in the previous implementation is part of the view, so that's why it's not needed here. Just remarking because it gave me a small pause.
| InstrumentValueType.DOUBLE, | ||
| Advice.empty())); | ||
| assertThat(descriptor1).isNotEqualTo(descriptor2).doesNotHaveSameHashCodeAs(descriptor2); | ||
| // Different instrument source type is not equal |
There was a problem hiding this comment.
Each of these commented sections seems like it's actually testing for a separate thing. Why not make these into actually separate test methods then?
There was a problem hiding this comment.
Yeah this about the code style question of whether a single unit test method should test multiple cases or just a single one. (I feel like we've talked about this before 😄)
Personally, I do both depending on the situation, mostly depending on how much setup there is for each case. If the setup is small, then splitting each case out into its own method feels like unnecessary boiler plate on the author and reduced readability. On the other hand, if there's lots of special setup and you have to do things like reset the state of mocks, then it becomes fairly obvious to split out into separate methods. There's plenty of examples of both strategies in this repo. In this particular test, I was refactoring an existing test so stuck with the existing pattern. But even if it was new, I probably would have opted to keep all the not equals cases in a single test.
There was a problem hiding this comment.
[...] feels like unnecessary boiler plate on the author and reduced readability.
Until a test fails, and you have to dive into a line of code from a stack trace instead of quickly getting a meaningful test name that matches a method name.
I was refactoring an existing test so stuck with the existing pattern
Yeah, I respect the need to limit change range in a single PR.
There was a problem hiding this comment.
Until a test fails, and you have to dive into a line of code from a stack trace instead of quickly getting a meaningful test name that matches a method name.
Assertj relieves this with the ability to name / describe assertions. Didn't use it here tho, but probably should in cases where a single test method verifies multiple cases.
jack-berg
force-pushed
the
fix-instrument-identity
branch
from
94d94cf
to
b0b030b
Compare
Resolves #5683.
Instruments with names which are case-insensitive equal contribute to same metric, advice is not part of instrument identity.
Embodies the comment here.