paho.mqtt.java icon indicating copy to clipboard operation
paho.mqtt.java copied to clipboard

Test Smell: ''assertEquals'' assertions with the wrong parameter order

Open TestSmell opened this issue 3 years ago • 0 comments

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 image 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:

  1. testMsgProperties() in BasicTest.java
  2. testDecodingComplexMqttSubscribe() in MqttSubscribeTest.java
  3. testConnectTimeout() in SendReceiveAsyncTest.java
  4. testBufferedMessageTopicAlias() in OfflineBufferingTest.java

TestSmell avatar Aug 15 '22 08:08 TestSmell