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

Introduce Refaster templates for AbstractComparableAsserts #225

Merged
merged 16 commits into from
Sep 18, 2022

Conversation

CoolTomatos
Copy link
Contributor

@CoolTomatos CoolTomatos commented Sep 6, 2022

❗ This PR is on top of #237

With assertJ, sometimes comparisons are evaluated as booleans.
The introduced templates replace them with methods from the AbstractComparableAssert API.


For example

assertThat(1 <= 2).isTrue();

will be then replaced with

assertThat(1).isLessThanOrEqualTo(2);

Further more,

assertThat(1 > 0).isTrue();

will first be replaced with

assertThat(1).isGreaterThan(0);

and then

assertThat(1).isPositive();

@CoolTomatos CoolTomatos self-assigned this Sep 6, 2022
@CoolTomatos CoolTomatos requested a review from rickie September 6, 2022 10:25
@CoolTomatos CoolTomatos force-pushed the CoolTomatos/abstract_comparable_assert branch 3 times, most recently from 0c73ba6 to b502fbf Compare September 6, 2022 15:34
@CoolTomatos CoolTomatos marked this pull request as ready for review September 6, 2022 15:44
Comment on lines 30 to 37
return ImmutableSet.of(
assertThat(1.0 == 2.0).isTrue(),
assertThat(1.0 != 2.0).isFalse(),
assertThat((byte) 1 == (byte) 2).isTrue(),
assertThat(1F == 2F).isTrue(),
assertThat(1 == 2).isTrue(),
assertThat(1L == 2L).isTrue(),
assertThat((short) 1 == (short) 2).isTrue());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

At the beginning, I added separate templates for different primitive types like short, long, int, float and byte.
However, the double templates render all the other ones obsolete.
So I removed them and added the primitive types here in the test case.

@CoolTomatos CoolTomatos force-pushed the CoolTomatos/abstract_comparable_assert branch 3 times, most recently from 2346fee to 264ee51 Compare September 6, 2022 20:00
@Stephan202 Stephan202 force-pushed the CoolTomatos/abstract_comparable_assert branch from 264ee51 to 9d7b2fc Compare September 8, 2022 16:23
Copy link
Member

@Stephan202 Stephan202 left a 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. Also added some changes that should be moved to a separate PR. Not yet done reviewing, but need to head to the train 😄

final class AssertJComparableTemplates {
private AssertJComparableTemplates() {}

static final class AbstractComparableAssertActualIsEqualByComparingToExpected<
Copy link
Member

Choose a reason for hiding this comment

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

Generally we'd name this type AssertThatIsEqualByComparingTo; will push a proposal :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Was struggling quite a bit about how to name stuff here. Consulted @rickie with it as well.
But the proposal looks good to me.

Copy link
Member

Choose a reason for hiding this comment

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

Yes you are right, this part isn't easy.

I recall discussing a template where we would've had clashes if we didn't use the parameter names in the Refaster template name. Where possible we indeed like to simplify and omit the AbstractComparable, actual and expected.

In the previous case that is mentioned here we would've probably needed this setup because of the clashes 😉.

Copy link
Member

Choose a reason for hiding this comment

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

Just saying: an extra argument for picking up the task of auto-suggesting/fixing Refaster template names. I expect this'll be a topic for most/all upcoming Refaster pull requests ;)

Comment on lines 29 to 46
ImmutableSet<AbstractAssert<?, ?>> testAbstractDoubleAssertActualIsEqualToExpected() {
return ImmutableSet.of(
assertThat(1.0 == 2.0).isTrue(),
assertThat(1.0 != 2.0).isFalse(),
assertThat((byte) 1 == (byte) 2).isTrue(),
assertThat(1F == 2F).isTrue(),
assertThat(1 == 2).isTrue(),
assertThat(1L == 2L).isTrue(),
assertThat((short) 1 == (short) 2).isTrue());
}
Copy link
Member

Choose a reason for hiding this comment

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

Very nice that it applies to other types as well. In fact, I see that we can slightly simplify another check 👀

Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

Added another commit :)

@@ -45,6 +49,26 @@ AbstractDoubleAssert<?> after(AbstractDoubleAssert<?> doubleAssert, double n) {
}
}

static final class AssertThatIsEqualTo {
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps AssertJNumberTemplates is a better location for these checks; that matches e.g. the AssertThatIsOdd check. Will have a look.

Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

Added two more commits. I'll circle back to this PR "soon", but it's close to done. Nice!

Comment on lines 27 to 31
@BeforeTemplate
AbstractBooleanAssert<?> before(boolean actual, boolean expected) {
return Refaster.anyOf(
assertThat(actual == expected).isTrue(), assertThat(actual != expected).isFalse());
}
Copy link
Member

Choose a reason for hiding this comment

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

Here and below I added boolean support, but those cases don't belong in this class. Still pondering another setup.

Comment on lines 33 to 43
@BeforeTemplate
AbstractBooleanAssert<?> before(double actual, double expected) {
return Refaster.anyOf(
assertThat(actual == expected).isTrue(), assertThat(actual != expected).isFalse());
}

@AfterTemplate
@UseImportPolicy(STATIC_IMPORT_ALWAYS)
AbstractBooleanAssert<?> after(boolean actual, boolean expected) {
return assertThat(actual).isEqualTo(expected);
}
Copy link
Member

Choose a reason for hiding this comment

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

These checks apply to primitive number types only, so arguably me moving them to AssertJNumberTemplates isn't correct either. Perhaps we need a synthetic AssertJPrimitiveTemplates class. TBD.

Copy link
Member

Choose a reason for hiding this comment

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

AssertJPrimitiveTemplates sounds like a good idea. I was thinking whether the convention is always clear as to when to put it in there, but yeah it is. So I'd say it's a good idea.

Comment on lines 326 to 230
// XXX: This template also matches (unlikely) expressions of the form `assertThat(someChar %
// 2).isEqualTo(1)`, for which the replacement AssertJ expression is invalid.
Copy link
Member

Choose a reason for hiding this comment

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

Here and below: TBD whether I'll move the extra changes to a separate PR, or (i.c.w. a suitable commit message) keep them in this PR.

Copy link
Member

Choose a reason for hiding this comment

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

To be 100% correct we could add a Matcher for that? I'd be up for creating that in refaster-support. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Indeed a Matcher could help here. It would be niche, but still. If you're up for this, we should first extract aa820c5 from this branch, as that will simplify the testing of such Matchers. I can open a PR for that ~later today.

Copy link
Member

Choose a reason for hiding this comment

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

^ I just opened #232; feel free to move the relevant changes to a PR on top of that one :)

Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

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

Left some answers, the code looks good. Not yet approving because we need to settle on some things 😄.

Thanks for opening the PR @CoolTomatos 🚀 !

Comment on lines 33 to 43
@BeforeTemplate
AbstractBooleanAssert<?> before(double actual, double expected) {
return Refaster.anyOf(
assertThat(actual == expected).isTrue(), assertThat(actual != expected).isFalse());
}

@AfterTemplate
@UseImportPolicy(STATIC_IMPORT_ALWAYS)
AbstractBooleanAssert<?> after(boolean actual, boolean expected) {
return assertThat(actual).isEqualTo(expected);
}
Copy link
Member

Choose a reason for hiding this comment

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

AssertJPrimitiveTemplates sounds like a good idea. I was thinking whether the convention is always clear as to when to put it in there, but yeah it is. So I'd say it's a good idea.

Comment on lines 326 to 230
// XXX: This template also matches (unlikely) expressions of the form `assertThat(someChar %
// 2).isEqualTo(1)`, for which the replacement AssertJ expression is invalid.
Copy link
Member

Choose a reason for hiding this comment

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

To be 100% correct we could add a Matcher for that? I'd be up for creating that in refaster-support. WDYT?

@rickie
Copy link
Member

rickie commented Sep 9, 2022

Added a commit to move the templates to AssertJPrimitiveTemplates.

@ferdinand-swoboda
Copy link
Contributor

Thanks for tagging, I think your PR is in very qualified hands, though 🙂

Let's get @CoolTomatos a shiny sticker to tell the world of this project 😄

@rickie
Copy link
Member

rickie commented Sep 10, 2022

Let's get @CoolTomatos a shiny sticker to tell the world of this project 😄

That sounds like a good idea 😄.

@Stephan202 Stephan202 force-pushed the CoolTomatos/abstract_comparable_assert branch from 7885a2c to b4a1581 Compare September 10, 2022 14:28
Copy link
Member

@Stephan202 Stephan202 left a 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 will extract some changes from this PR, but it LGTM otherwise.

Suggested commit message:

Introduce `AssertJComparableTemplates` and `AssertJPrimitiveTemplates` (#225)

import org.assertj.core.api.AbstractAssert;
import tech.picnic.errorprone.refaster.test.RefasterTemplateTestCase;

final class AssertJStringTemplatesTest implements RefasterTemplateTestCase {
Copy link
Member

Choose a reason for hiding this comment

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

^ We should update the class name. (Another thing to automate 😅)

Copy link
Member

Choose a reason for hiding this comment

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

Another thing to automate 😅

I filed #233 :)

@@ -28,6 +29,7 @@ final class RefasterTemplatesTest {
AssertJMapTemplates.class,
AssertJObjectTemplates.class,
AssertJOptionalTemplates.class,
AssertJPrimitivesTemplates.class,
Copy link
Member

Choose a reason for hiding this comment

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

Seems we favour singular here:

Suggested change
AssertJPrimitivesTemplates.class,
AssertJPrimitiveTemplates.class,

@rickie rickie force-pushed the CoolTomatos/abstract_comparable_assert branch from b4a1581 to 61ae225 Compare September 13, 2022 09:48
@rickie rickie changed the base branch from master to rossendrijver/char_matcher September 13, 2022 09:48
@rickie
Copy link
Member

rickie commented Sep 13, 2022

Filed #237 and changed the base for this branch to that one. Now the diff looks clean 🚀 !

@rickie
Copy link
Member

rickie commented Sep 13, 2022

Thanks for tagging, I think your PR is in very qualified hands, though 🙂

I assume you don't want to review anymore @ferdinand-swoboda ? If not, we can remove the request for review.

@CoolTomatos CoolTomatos removed the request for review from ferdinand-swoboda September 13, 2022 15:26
Copy link
Member

@rickie rickie left a comment

Choose a reason for hiding this comment

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

Forgot to approve after moving out some changes.

The code looks nice, thanks for the contribution @CoolTomatos 🚀 !

Suggested commit message LGTM.

@Stephan202 Stephan202 force-pushed the rossendrijver/char_matcher branch from 774f8b7 to cb9fc83 Compare September 17, 2022 17:43
@Stephan202 Stephan202 force-pushed the CoolTomatos/abstract_comparable_assert branch from 61ae225 to d4f9dc4 Compare September 18, 2022 11:36
@Stephan202 Stephan202 added this to the 0.2.1 milestone Sep 18, 2022
Copy link
Member

@Stephan202 Stephan202 left a comment

Choose a reason for hiding this comment

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

Rebased. We'll merge once #237 is merged. Thx for the PR @CoolTomatos!

Base automatically changed from rossendrijver/char_matcher to master September 18, 2022 12:39
@Stephan202 Stephan202 force-pushed the CoolTomatos/abstract_comparable_assert branch from d4f9dc4 to 12518ec Compare September 18, 2022 12:43
@Stephan202
Copy link
Member

Rebased; will merge once built.

@Stephan202 Stephan202 merged commit 8e7d04a into master Sep 18, 2022
@Stephan202 Stephan202 deleted the CoolTomatos/abstract_comparable_assert branch September 18, 2022 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants