Let's take a look at the definitions of assertequals () by JUnit and testng respectively:
JUnit:
Static voidAssertequals(Java. Lang. ObjectExpected, Java. Lang. ObjectActual)
Static voidAssertequals(Java. Lang. StringMessage, Java. Lang. ObjectExpected, Java. Lang. ObjectActual)
Testng:
Static voidAssertequals(Java. Lang. ObjectActual, Java. Lang. ObjectExpected)
Static voidAssertequals(Java. Lang. ObjectActual, Java. Lang. ObjectExpected, Java. Lang. StringMessage)
Ignore the type of each parameter and ignore it. review the order of actual, expected, and message parameters:
The order in JUnit is: (Message), expected, Actual.
The order in testng is: Actual, expected, (Message ).
The slight difference is that the order of actual (actual value) and expected (expected value), when message (information text) exists, it is relative to the other two parameters. In JUnit, the message (if it exists) is given priority, followed by expected, and again actual. In testng, it is exactly the opposite. Actual is given priority, the second is expected, and the second is message.
In comparison, I think testng's definition of assertequals () is more in line with human thinking logic, that is, the so-called "user-friendly" is more powerful. Of course, this is my opinion.
When I first saw the definition of assertequals () in JUnit, I was wondering why actual was not in front of expected? The first time I saw testng's definition of assertequals () Today, I suddenly felt like a hero. Of course, this is a bit of "coming soon.
In this regard, I applaud testng!