You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When migrating assertEquals, detect properly when to use assertArrayEquals.
I believe that between JUnit4 and JUnit5 assertEquals behaviour changed. It compares direct object references now.
The following test case below passes in JUnit4 but fails with JUnit5 assertEquals.
We are comparing two Object[]. Therefore we should use assertArrayEquals instead.
What precondition(s) should be checked before applying this recipe?
Thanks for reporting this issue here and in Slack! Indeed looks like a case we had not consciously covered before, so great to have a sample and see if we can implement a quick fix; Would you be willing to help kick start development with a Draft pull request that adds Assert.assertEquals(new Object[1], new Object[1]); to the unit test fro AssertToAssertionsTest? From there it should then be easy to step through with the debugger and potentially even contribute the fix.
What problem are you trying to solve?
When migrating assertEquals, detect properly when to use assertArrayEquals.
I believe that between JUnit4 and JUnit5 assertEquals behaviour changed. It compares direct object references now.
The following test case below passes in JUnit4 but fails with JUnit5 assertEquals.
We are comparing two Object[]. Therefore we should use assertArrayEquals instead.
What precondition(s) should be checked before applying this recipe?
Describe the situation before applying the recipe
Describe the situation after applying the recipe
Have you considered any alternatives or workarounds?
Any additional context
I think currently it is not differentiated whether the compared types are just objects or arrays of objects.
Are you interested in contributing this recipe to OpenRewrite?
The text was updated successfully, but these errors were encountered: