Assertions refactoring #1566
Assertions refactoring #1566
Conversation
There was a problem hiding this comment.
[question to reviewers] In original framework we had assertSum method with overloaded version accepting isMonotonic parameter added. This was little unclear to me for two reasons:
It was not obvious that assertSum without isMonotonic parameter was the same as assertSum(isMonotonic=true)
In YAML we used instrument types gauge, counter, updowncounter, while in assertions we used assertGauge, assertSum with and without isMonotonic parameter.
That's why I decided to implement assertGauge, assertCounter and assertUpDownCounter method families here.
I know it may lead to more methods to be implemented but for me this new API is cleaner.
What do you think about this approach?
Method names improvement.
refactor with custom assertj assertions
Minor refactorings, mostly renaming. Fixed typos.
| /* | ||
| List<String> gcLabels = | ||
| Arrays.asList( | ||
| "Code Cache", | ||
| "PS Eden Space", | ||
| "PS Old Gen", | ||
| "Metaspace", | ||
| "Compressed Class Space", | ||
| "PS Survivor Space"); | ||
| List<String> gcCollectionLabels = Arrays.asList("PS MarkSweep", "PS Scavenge"); | ||
| */ |
There was a problem hiding this comment.
leftover from my PR, we should remove it
Preview of new metrics assertions framework.
Assertion errors are now reported in much more compact and descriptive form.
Error message always contain only data related to failing metric, as opposed to old assertions where all received metrics were listed and it was extremely hard to find what is wrong in large set of metrics.