-
Notifications
You must be signed in to change notification settings - Fork 39
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
Introduce IsEmpty
matcher for use by Refaster templates
#744
Conversation
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
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.
Some context.
StepVerifier.create(Mono.just("foo")).expectNextMatches(s -> s.equals("bar")), | ||
StepVerifier.create(Mono.just("baz")).expectNextMatches("qux"::equals)); | ||
Mono.just("foo").as(StepVerifier::create).expectNextMatches(s -> s.equals("bar")), | ||
Mono.just("baz").as(StepVerifier::create).expectNextMatches("qux"::equals)); |
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.
These .as(StepVerifier::create)
changes were not previously flagged by the tests, because the actual rule under test suggested a smaller replacement. The reason I noticed this now, is that for the StepVerifierStepIdentity
test cases I added a negative entry, in order to validate the @Matches
usage.
"import reactor.util.context.Context;", | ||
"", | ||
"class A {", | ||
" int[] negative1() {", |
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.
Keeping these counters in sync negatively impacts maintenance. Maybe in a separate PR we should consider a more compact test format for these matchers. (But for this PR I followed the established approach.)
" // BUG: Diagnostic contains:", | ||
" return new ArrayList<>(", | ||
" // BUG: Diagnostic contains:", | ||
" ImmutableList.of());", |
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.
Here and below: expressions split across multiple lines, to prove that the outer expression is (also) recognized as an empty collection.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
8c6a0ac
to
3f6e017
Compare
Kudos, SonarCloud Quality Gate passed! |
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
3f6e017
to
cdd2e3d
Compare
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
cdd2e3d
to
afb5064
Compare
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.
Rebased and added another commit: now even more empty collections are recognized, and AssertJMapRules
and AssertJRules
have been simplified accordingly.
ImmutableMultiset.of(), | ||
ImmutableSortedMultiset.of())), | ||
mapAssert.containsExactlyEntriesOf(wellTypedMap), | ||
mapAssert.containsExactlyInAnyOrderEntriesOf(wellTypedMap), |
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 case was previously not covered.
@BeforeTemplate | ||
AbstractMapAssert<?, ?, K, V> before(AbstractMapAssert<?, ?, K, V> mapAssert, Map<K, V> map) { | ||
AbstractMapAssert<?, ?, K, V> before( | ||
AbstractMapAssert<?, ?, K, V> mapAssert, Map<? extends K, ? extends V> map) { |
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.
Here and below: I generalized the matching a bit, just because I noticed. This likely applies to many other rules; eventually we'll write an Error Prone check for this.
assertThat(ImmutableMap.of(4, 0)) | ||
.containsExactlyInAnyOrderEntriesOf(ImmutableMap.of(1, 2, 3, 4)); |
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 one doesn't just use ImmutableMap.of(1, 2)
, because then another simplification kicks in.
assertThat(ImmutableMap.of(5, 0)).hasSameSizeAs(ImmutableMap.of()); | ||
assertThat(ImmutableMap.of(6, 0)).hasSameSizeAs(ImmutableMap.of(1, 2)); | ||
assertThat(ImmutableMap.of(7, 0)).isEqualTo(ImmutableMap.of()); | ||
assertThat(ImmutableMap.of(8, 0)).isEqualTo(ImmutableMap.of("foo", "bar")); |
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.
Likewise :)
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
afb5064
to
2d64df8
Compare
Rebased and resolved conflicts. |
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
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.
Hard to review in detail, but overall LGTM 👍🏻
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.
Pfff this is an insane PR! Really nice work @Stephan202 , the Matcher is amazing ✨ 🤯 !
Got some minor comments, let's merge this soon!
"", | ||
" int[][] positive2() {", | ||
" // BUG: Diagnostic contains:", | ||
" return new int[0][1];", |
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.
And the Lol, maybe not worth changing 50+ method names for something that is actually already covered.[1][0]
would maybe be interesting as that will fall through the first check of .get(0) == 0
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.
I'll have a closer look at your suggestion, but to the general point of method naming: that was quite painful for this PR indeed. I tried to remain consistent with other tests, but it did make me wonder: perhaps we should drop all those number suffixes in favour of something more descriptive.
(W.r.t. this PR: at some point I renumbered using a Vim macro ;).)
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.
W.r.t. the suggestion itself: return new int[1][0]
is used above, in method negative2
:)
void before( | ||
AbstractMapAssert<?, ?, K, V> mapAssert, | ||
@Matches(IsEmpty.class) Map<? extends K, ? extends V> wellTypedMap, | ||
@Matches(IsEmpty.class) Map<?, ?> arbitraryMap, |
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.
arbitraryTypedMap
maybe? To be inline with the previous one :)? arbitraryMap
sounds a bit odd IMO.
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.
Btw, this template looks so clean now ✨ !
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.
Grammatically it'd then be arbitrarilyTypedMap
. And that would be fine, I suppose, though this parameter stands in for "really any arbitrary map", and the current name covers that. (Not sure about raw Map
types; let's ignore those.)
But in the interest of getting this merged: will rename :)
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.
(We should then do a similar rename in AssertThatObjectEnumerableIsEmpty
.)
2d64df8
to
140895c
Compare
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.
Rebased and added a commit. @rickie feel free to merge.
Updated suggested commit message:
Introduce `IsEmpty` matcher for use by Refaster templates (#744)
While there, generalize a number of Refaster rules using this new matcher.
"", | ||
" int[][] positive2() {", | ||
" // BUG: Diagnostic contains:", | ||
" return new int[0][1];", |
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.
I'll have a closer look at your suggestion, but to the general point of method naming: that was quite painful for this PR indeed. I tried to remain consistent with other tests, but it did make me wonder: perhaps we should drop all those number suffixes in favour of something more descriptive.
(W.r.t. this PR: at some point I renumbered using a Vim macro ;).)
void before( | ||
AbstractMapAssert<?, ?, K, V> mapAssert, | ||
@Matches(IsEmpty.class) Map<? extends K, ? extends V> wellTypedMap, | ||
@Matches(IsEmpty.class) Map<?, ?> arbitraryMap, |
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.
Grammatically it'd then be arbitrarilyTypedMap
. And that would be fine, I suppose, though this parameter stands in for "really any arbitrary map", and the current name covers that. (Not sure about raw Map
types; let's ignore those.)
But in the interest of getting this merged: will rename :)
"", | ||
" int[][] positive2() {", | ||
" // BUG: Diagnostic contains:", | ||
" return new int[0][1];", |
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.
W.r.t. the suggestion itself: return new int[1][0]
is used above, in method negative2
:)
void before( | ||
AbstractMapAssert<?, ?, K, V> mapAssert, | ||
@Matches(IsEmpty.class) Map<? extends K, ? extends V> wellTypedMap, | ||
@Matches(IsEmpty.class) Map<?, ?> arbitraryMap, |
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.
(We should then do a similar rename in AssertThatObjectEnumerableIsEmpty
.)
Kudos, SonarCloud Quality Gate passed! |
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed. |
Suggested commit message:
As discussed offline with @rickie: this matcher could be used for #733 (assuming that it's extended to support
Mono<Void>
; that's not part of this PR.)