`MigrateHamcrestToAssertJ` handling of three arg `assertEquals` with numerical arguments

[ChenyuWang98]

int a= 120
assertEquals(120,a,1E-6) => assertThat(a).isCloseTo(120,within(1E-6))
assertEquals(120,a,1E-6) => assertThat(a).isEqualTo(120)

[timtebeek]

Thanks for reporting this! Could you clarify the type of a in your example?

int a = 120;
assertEquals(120, a, 1E-6);

Was a intentionally declared as int, or should it have been double?

• If a is a double, the recipe already correctly converts to assertThat(a).isCloseTo(120, within(1E-6)).
• If a is an int, the recipe currently converts to assertThat(a).isEqualTo(120) because assertThat(intValue).isCloseTo(...) in AssertJ requires Offset<Integer>, not Offset<Double> — so within(1E-6) wouldn't compile. The delta is also semantically meaningless for exact integer comparisons.

Knowing your intended type will help us determine the right fix here.

[ChenyuWang98]

Yes, I think you're right. In my case, the data type was int, but the result wasn't processed as int.

Thanks for reporting this! Could you clarify the type of a in your example?

int a = 120;
assertEquals(120, a, 1E-6);
Was a intentionally declared as int, or should it have been double?

• If a is a double, the recipe already correctly converts to assertThat(a).isCloseTo(120, within(1E-6)).
• If a is an int, the recipe currently converts to assertThat(a).isEqualTo(120) because assertThat(intValue).isCloseTo(...) in AssertJ requires Offset<Integer>, not Offset<Double> — so within(1E-6) wouldn't compile. The delta is also semantically meaningless for exact integer comparisons.

Knowing your intended type will help us determine the right fix here.

Yes, I think you're right. In my case, the data type was int, but the result wasn't processed as int.

The original statement is assertEquals(120, a, 1E-6).

The generated statement is assertThat(a).isCloseTo(120,within(1E-6)).
The expected result of the generated statement is assertThat(a).isEqualTo(120)