AssertEquals, what is relevant and what is expected?

Question

I always wondered what exactly the actual and expected assertEquals in libraries like TestNG.

If we read Java docs, we see:

 public static void assertEquals(... actual, ... expected) Parameters: actual - the actual value expected - the expected value 

In my opinion, the expected value is known, so we expect, and actual is the one we want to check. For example, suppose we want to test the fooBar function, which should always return 56 .

In that case, I would do: assertEquals(sth.fooBar(), 56) . But with a quick GitHub search, it seems like people are doing it the other way around, therefore assertEquals(56, sth.fooBar()) . But how can the expected value be sth.fooBar() when we don't even know this value? It seems that sth.fooBar() is the actual value that we are comparing with the expected one that we already know.

I know that there is no difference in the correctness of the test, but I would like to follow the "correct" method.

Answer 1

Most testing systems (the xUnit family) are based on the JUnit framework. The Assert family of functions in JUnit is in the format (expected, actual) ; it became a convention, and most other frameworks followed this convention.

Some frameworks (e.g. TestNG or NUnit 2.4+ for .NET) have canceled this order (using the constraint-based model for NUnit) to increase readability ("make sure the actual value - 56" feels more natural than "make sure 56 is the actual value ").

The bottom line is: stick to the convention of your framework. If you are using JUnit, first set the expected value. If you are using TestNG, first set the actual value. You are right, it does not matter in the test results when you accidentally change arguments. But this is of great importance in the default message that you receive from a failed test. When your reversed assertEquals(ShouldBeTrueButReturnsFalse(), true) in JUnit does not work, the default message says "expected [false] but found [true]", which should say "expected [true] but found [false]". This is confusing, to say the least, and you don’t have to deal with the possible wrong direction of this message.

Some of the unit tests in the Github link you provide are not consistent and have the same problem. Do not do that. Follow the agreement on your structure .

Answer 2

The answer is simple. JUnit has the reverse order of arguments. See the example below:

JUnit:

void assertEquals(Object expected, Object actual)

TestNG:

void assertEquals(int actual, int expected)

Answer 3

I also had the same confusion.

But the confusion is that a Github search returns the assertEquals syntax for both TestNG and junit. You are right with the expected and real understanding.

TestNG: assertEquals(Object actual, Object expected)

junit: assertEquals(Object expected, Object actual)

For example, in testNG, the result is below code

int x=1+2; assertEquals(x,2);

is an:

 java.lang.AssertionError: expected [2] but found [3] Expected :2 Actual :3 

Answer 4

You can use:

 String expectedTitles[] = {"value-1", "value-2", "value-3". "value-14")}; List<String> expectedTitlesList = Arrays.asList(expectedTitles); Assert.assertTrue(expectedTitlesList.contains(("value-to-compare"))); 

with maven:

 <!-- https://mvnrepository.com/artifact/junit/junit --> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.4</version> </dependency> <!-- https://mvnrepository.com/artifact/org.hamcrest/hamcrest-all --> <dependency> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-all</artifactId> <version>1.3</version> </dependency>