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
Description:
we detect that some assertions in your test code have the wrong parameter orders.
For example, the test case named ''testToByteArrayConvertsInt()'' in ''IdentifierTest.java'' writes the ''assertEquals'' assertion as
However, referring to the API documentation of ''org.junit.Assert’’ is ''assertEquals(Object expected, Object actual)''.
Negative:
Using ''assertEquals()'' with the wrong parameter order is a bad test practice.
Because once the test case fails, the ''assertEquals()'' assertion with the wrong parameter order will give the wrong log information.
The log information will say:’’ java.lang.AssertionError: expected [actual value] but found [ excepted value]’’, where it should have said "java.lang.AssertionError: expected [excepted value] but found [actual value]''.
This is confusing, to say the least, and you shouldn't have to deal with a possible misdirection of that message.
Solution:
Generally, the excepted value should be a known value, such as a real number, a string, etc.
The actual value should be the result of the method-under-test.
The best way to eliminate the test smell is to exchange the parameter in ''assertEquals'' assertions.
We list other test cases with the same problem as follows:
testToByteArrayConvertsHex() in IdentifierTest.java
testToByteArrayConvertsInt() in IdentifierTest.java
testToByteArrayConvertsUuids() in IdentifierTest.java
testCalculateAccuracyWithRssiEqualsPowerOnInternalProperties() in BeaconTest.java
stopRangingBeaconsInRegionTest() in BeaconManagerTest.java
startRangingBeaconsInRegionMultipleInvocationsTest() in BeaconManagerTest.java
testRecognizeBeacon() in AltBeaconTest.java ....
The text was updated successfully, but these errors were encountered:
Hi!
Description:
we detect that some assertions in your test code have the wrong parameter orders.
For example, the test case named ''testToByteArrayConvertsInt()'' in ''IdentifierTest.java'' writes the ''assertEquals'' assertion as
However, referring to the API documentation of ''org.junit.Assert’’ is ''assertEquals(Object expected, Object actual)''.
Negative:
Using ''assertEquals()'' with the wrong parameter order is a bad test practice.
Because once the test case fails, the ''assertEquals()'' assertion with the wrong parameter order will give the wrong log information.
The log information will say:’’ java.lang.AssertionError: expected [actual value] but found [ excepted value]’’, where it should have said "java.lang.AssertionError: expected [excepted value] but found [actual value]''.
This is confusing, to say the least, and you shouldn't have to deal with a possible misdirection of that message.
Solution:
Generally, the excepted value should be a known value, such as a real number, a string, etc.
The actual value should be the result of the method-under-test.
The best way to eliminate the test smell is to exchange the parameter in ''assertEquals'' assertions.
We list other test cases with the same problem as follows:
The text was updated successfully, but these errors were encountered: