Chapter 3. Unit Tests with no Collaborators
Listing 3.4. JUnit summary test result
Running com.practicalunittesting.MoneyTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
Remember to always look at the status line and react immediately if you see failed or skipped tests. Also, take note of the number of tests executed. It can happen, especially at the beginning of your testing journey, that your test will not run at all!
3.3.1. Test Results
Tests executed by hand (see Section A.1 for some discussion of this) can end up with a plethora of results, ranging from "it works for me", through "I am not sure, but I do not have time to investigate it any further", to "it works… and this exception has always been there". In the case of automated tests things look different. There are only a few possible outcomes. Let us take a closer look at them.
An automated test ends up in one of two states: as passed or failed. Two other outcomes are less frequent - a test can be skipped or finish with error. There is no place for "I think it should work now" in automated tests!
If all assertions of a test are met, and no unexpected exceptions are thrown, then that test passes. A passed test is usually marked with a green color by IDEs and test reports.
If an unexpected exception is thrown then the test fails. This happens if some assertion is unmet, or you have a bug in your code which results in, for example ArraysOutOfBoundsException. Your IDE and test reports will mark such a failed test with a red color.
A test can be skipped (which means it was not run at all) if some of its assumptions were not met (see Section 6.3), or if the user decided explicitly that it should be skipped. Such a test is usually marked with a yellow color.
Finally, a test can end up as an error, if some unexpected condition occurred that interrupted its execution. This is rather an uncommon situation and usually indicates that something is wrong with your test code. It can happen, for example, if a test method expects some parameters but they were not provided (see Section 3.6). Just like failed tests, tests which have ended in an error state are also marked with a red color. They are usually grouped with failed tests on reports.
3.4. JUnit Assertions
We have already encountered one assertion - assertEquals(). Let me remind you what it looked like:
Listing 3.5. assertEquals() in action
assertEquals(10, money.getAmount()); assertEquals("USD", money.getCurrency());
Table 3.1 shows assertion methods of the org.junit.Assert class. Most of the methods displayed come in multiple variants with different parameters (e.g. assertEquals() accepts two parameters of type double, long, String, and others, too). Please refer to JUnit Javadocs for detailed information on available assertion methods.
22
|
|
Chapter 3. Unit Tests with no Collaborators |
|
|
Table 3.1. JUnit assertions |
||
|
|
|
|
|
assertion method |
|
description |
|
|
|
|
|
assertEquals() |
|
Uses the equals() method to verify that objects are identical. |
|
|
|
|
|
assertTrue() |
|
Checks if the condition is true. |
|
|
|
|
|
assertFalse() |
|
Checks if the condition is false. |
|
|
|
|
|
assertNull() |
|
Checks if the object is null. |
|
|
|
|
|
assertNotNull() |
|
Checks if the object is not null. |
|
|
|
|
|
assertNotEquals() |
|
Uses the equals() method to verify that objects are not identical. |
|
|
|
|
|
assertArrayEquals() |
|
Checks if two arrays contain the same objects in the same order. |
|
|
|
|
|
assertSame() |
|
Uses == to verify that objects are the same. |
|
|
|
|
|
assertNotSame() |
|
Uses == to verify that objects are not the same. |
|
|
|
|
|
assertThat() |
|
An entry point to the matchers-based assertions which we will |
|
|
|
discuss in Section 6.6. |
|
|
|
|
Some of the above methods (e.g. assertTrue(), assertNotNull()) take only one parameter and an optional message (see Section 3.5). Others – e.g. assertEquals() and assertSame() – take two parameters and an optional message. In such a case, the order of parameters is the following:
1.(optional) message.
2.expected value,
3.actual value.
You might ask what difference the order of the first two parameters makes. Is there any difference between comparing A to B and comparing B to A? Of course, there is no difference in terms of result. They are the same/equal, or they are not, right? You will notice the difference only when the test fails. We will get to that soon.
Another point is that you should really learn all of the above assertions and make use of them. At first you might be tempted to stick with just the simplest: i.e. assertTrue() and assertFalse(). They will allow you to verify just about anything, provided that you write a condition which evaluates to true or false. True, but verifying results with assertSame(), assertNull() or assertNotEquals() will make your test code much more readable. Remember, "use the right tool for the job"! This holds on every level.
We will take a different approach to assertions writing in Section 6.6.
3.5. Failing Test
Let us see what happens when a test fails. It is inevitable that you will see many failing tests, so we had better get well acquainted with it.
To make our test fail, we need to introduce a small change into the constructor of the Money class.
23