Hi!
Description:
we detect that some assertions in your test code have the wrong parameter orders.
For example, the test case named ''testMsgProperties()'' in ''BasicTest.java'' writes the ''assertEquals'' assertion as
However, referring to the API documentation of ''org.junit.Test'' 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:
testMsgProperties() in BasicTest.java
testDecodingComplexMqttSubscribe() in MqttSubscribeTest.java
testConnectTimeout() in SendReceiveAsyncTest.java
testBufferedMessageTopicAlias() in OfflineBufferingTest.java
Hi! Description: we detect that some assertions in your test code have the wrong parameter orders. For example, the test case named ''testMsgProperties()'' in ''BasicTest.java'' writes the ''assertEquals'' assertion as
However, referring to the API documentation of ''org.junit.Test'' 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: