assertThat, assertEquals, assertTrue

Last night was the Open House event of AgileChina 2011, and I was a volunteer in the coding session. The main purpose of the Coding session is to let the participating developers experience the process of pair programming, test-driven development and refactoring. We have prepared four different types of programming questions. The company will have eight or nine colleagues and participating peers to experience this process:

Time Sheet

Supermarket Checkout

Source code line number statistics

Blackjack Game

Overall, the event was quite successful, except for two small episodes:

1. The company wanted to I bought a new keyboard and mouse, but they feel too tactile when typing, and the keys on the keyboard are flat. One participant may not be very familiar with the keyboard and always mistakenly types enter into a slash many times.

2. The system's lock screen shortcut keys conflict with the IDE's formatting code shortcut keys, which resulted in me typing the wrong key twice to lock the screen. Moreover, the machine does not belong to me, so I have to find other colleagues to help input it. Password, damn it.

In the last round of Pair, a classmate asked: Why not use assertEquals? I see that you are all using assertThat, and it seems that the use of assertEquals, assertTrue, etc. is not highly recommended.

Because the event was almost over and we were going to take a group photo, we simply answered. Here is a detailed answer to this question.

What do we want to get from assertions

What do we want to get from assertions in tests? Just displaying a red bar after the test fails is not what we want. In addition, we also want to get some information from the test:

1. Where did the test fail? Is there a line of code? All assertions can provide this function

2. Why the test failed is difficult to define. Most assertions can provide similar functions:

Desired results vs actual results

But different assertions provide different information. There are also problems where comparisons are difficult to make using simple assertions like equality. Moreover, assertions also have a very important role: documentation. That is, when you read the test code, you see the assertions as if you were seeing all the expectations. And very clear expectations.

Actual example

Look at the second parameter of assertThat. It accepts a Matcher8742468051c85b06f0a0af9e3e506b5c. There are very rich Matcher implementations in org.hamcrest. For example, now our API returns a list of user objects, and we want to assert that this list contains the user we expect. There is a Matcher such as hasItem in hamcrest:

   1: assertThat(userDAO.findAll(), hasItem(expected));

What should we do if we use other assertions?

   1: assertTrue(userDAO.findAll().contains(expected));

Okay, here’s the problem, if both assertions above fail, the failure message of the first assertion will be:

The expected result contains expected….

But actually...all the users returned by findAll will be printed here

And what about the second assertion? It's like this:

Expected to be true, actually false

Which one is more reliable? Obviously the failure information of the first assertion is more helpful for us to find the problem.

For documentation, let’s look at this requirement again: the user list returned by the assertion does not contain the given user:

   1: assertThat(userDAO.findAll(), not(hasItem(expected));

Is it very clear? You won’t feel it when reading this assertion. When you are reading code, it is like reading Spec. If other assertions are used:

   1: assertFalse(userDAO.findAll().contains(expected));

is not as well documented as the previous one.

Of course, for some APIs that return true or false, or return a single value, you can also use other assertions without much problem. For example:

   1: assertEquals(userDAO.findBy(id), expected);

Ah, what? You said I used it wrong, why? After checking the parameter description, I found that the expected value should be placed in the first parameter, and the actual value should be placed in the second parameter. It’s so helpless. My memory is not good, so I always make these mistakes. Fortunately, we have assertThat:

   1: assertThat(userDAO.findBy(id), is(expected));

Will you still make mistakes?

The above is the content of assertThat, assertEquals, and assertTrue. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!