Chapter 6. Things You Should Know
6.12. Testing Collections
Sometimes the methods of SUTs return collections whose content is the outcome of an SUT’s business logic: of course, this is something to be tested. This section provides some information on testing collections and their content.
6.12.1. The TDD Approach - Step by Step
First of all, a few remarks on testing collection content with TDD. It is advisable to do this step by step. Start with a simple assertion which verifies that a returned collection is not null. Watch the test fail (as a default implementation created by your IDE will probably return null). Make the test pass by returning a new collection. Add another assertion verifying whether or not the returned collection has the expected number of elements. Now start verifying the content.
An example of the resulting test code is shown in Listing 6.41. It contains many assertions, each progressively more restrictive than the previous one.
Listing 6.41. TDD collection content testing
public class UserTest {
@Test
public void shouldReturnUsersPhone() { User user = new User(); user.addPhone("123 456 789");
List<String> phones = user.getPhones();
assertNotNull(phones); 
assertEquals(1, phones.size());
assertTrue(phones.contains("123 456 789"));
}
}
Always worth checking, as it defends us from a NulPointerException being thrown in consecutive assertions.
Even though this pattern might seem unnatural at first, the benefit is that if anything goes wrong, you can pinpoint bugs with 100% accuracy. But of course, you do not have to be so meticulous - if you feel like moving in larger steps, then by all means do so. You might save a few seconds here, but on the other hand you might lose much more time later. It is for you to decide.
As shown in Listing 6.41, it is possible to test collections’ content using the common assertions of JUnit: e.g. assertEquals(), assertTrue() and assertFalse(). In the event that you should need to compare the content of two collections, JUnit does not offer much support. Fortunately, there are many other libraries that we can use from within JUnit tests which can help us with this task.
6.12.2. Using External Assertions
Sometimes you will need more for collections testing than JUnit can offer. In such cases, you may refer to other frameworks, which can be combined with JUnit tests. Below you will find examples of
133
Chapter 6. Things You Should Know
Unitils21, Hamcrest22 and FEST Fluent Assertions23 usage for collections testing. However, please make sure that you read the documentation for each of these projects, as this book does not set out to comprehensively describe all of their features.
The use of matchers libraries (like Hamcrest and FEST) is described in detail in Section 6.6.
For the next few examples let us assume that two sets - setA and setB - are defined in the following way:
Listing 6.42. Sets
Set<String> setA = new LinkedHashSet<String>();
Set<String> setB = new LinkedHashSet<String>();
String s1 = "s1";
String s2 = "s2";
setA.add(s1);
setA.add(s2);
setB.add(s2);
setB.add(s1);
Set setA contains "s1" and "s2" (in this order).
Set setB contains "s2" and "s1" (in this order).
Unitils
The test shown in Listing 6.43 gives an example of testing collections content using Unitils. With Unitils, it is up to the programmer to decide what it means for two collections to be considered "equal".
Listing 6.43. Collection content testing with Unitils
import org.unitils.reflectionassert.ReflectionComparatorMode; import static org.unitils.reflectionassert
.ReflectionAssert.assertReflectionEquals;
public class SetEqualityTest {
// same setA and setB as presented previously
@Test
public void twoSetsAreEqualsIfTheyHaveSameContentAndSameOrder() { assertReflectionEquals(setA, setB); 
}
@Test
public void twoSetsAreEqualsIfTheyHaveSameContentAndAnyOrder() { assertReflectionEquals(setA, setB,
ReflectionComparatorMode.LENIENT_ORDER);
}
}
21http://www.unitils.org/
22http://code.google.com/p/hamcrest/
23http://fest.codehaus.org/Fluent+Assertions+Module
134
Chapter 6. Things You Should Know
Unitils library classes are imported.
This will fail because assertReflectionEquals() verifies both the content and the order of collections elements by default.
By setting ReflectionComparatorMode to LENIENT_ORDER we can alter the
assertionReflectionEquals() so that it only verifies the content and is indifferent to the ordering of elements.
Unitils offers some other assertions that are helpful for collections testing too. For example, you can use it to verify that elements of a collection have certain values of a specific property. Please refer to Unitils documentation for more information.
In cases of test failure, some very detailed information about the collections subject to comparison will be printed. Below, an exemplary error message is shown. It was caused by a failed test, which asserted the equality of two collections that were not exactly equal.
Listing 6.44. Detailed error message of Unitils assertions
Expected: ["s1", "s2"], actual: ["s2", "s1"]
--- Found following differences ---
[0]: expected: "s1", actual: "s2" [1]: expected: "s2", actual: "s1"
Testing Collections Using Matchers
Matcher libraries offer some interesting features that are helpful for collections testing. As discussed in Section 6.6, they furnish two main benefits:
•very readable code,
•very detailed error messages (in case of test failure).
Both of the above can be observed in the examples given in this section.
FEST Fluent Assertions, which is a part of FEST library, offers many assertions which can simplify collections testing. Listing 6.45 shows some of them. It provides a fluent interface24, which allows for the chaining together of assertions.
24See http://martinfowler.com/bliki/FluentInterface.html
135
Chapter 6. Things You Should Know
Listing 6.45. Testing collections with FEST Fluent Assertions
import static org.fest.assertions.Assertions.assertThat; import static org.fest.assertions.MapAssert.entry; 
public class FestCollectionTest {
// same setA and setB as presented previously
@Test
public void collectionsUtilityMethods() { assertThat(setA).isNotEmpty()
.hasSize(2).doesNotHaveDuplicates(); 
assertThat(setA).containsOnly(s1, s2); 
}
@Test
public void mapUtilityMethods() { HashMap<String, Integer> map
= new LinkedHashMap<String, Integer>(); map.put("a", 2);
map.put("b", 3);
assertThat(map).isNotNull().isNotEmpty()
.includes(entry("a", 2), entry("b", 3))
.excludes(entry("c", 1));
}
}
A few imports of FEST methods.
As mentioned previously FEST provides a fluent interface, which allows for the chaining together of assertions. In this the case verification of emptiness, size and the absence of duplicates all gets fitted into a single line of code, but the code is still readable.
A specialized method, containsOnly(), verifies that the given collection contains nothing other than the elements specified.
Similarly, in the case of maps specialized assertions allow for a very readable and concise test.
A different set of assertions is provided by the Hamcrest library. Some of these are shown below:
136
Chapter 6. Things You Should Know
Listing 6.46. Testing collections with Hamcrest assertions
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.collection.IsCollectionContaining.hasItem; import static org.hamcrest.collection.IsCollectionContaining.hasItems; import static org.hamcrest.collection.IsMapContaining.hasEntry; import static org.hamcrest.collection.IsMapContaining.hasKey;
public class HamcrestCollectionTest {
// same setA and setB created as in previous example
@Test
public void collectionsUtilityMethods() { 
assertThat(setA, hasItem(s1)); assertThat(setA, hasItem(s2)); assertThat(setA, hasItem("xyz")); assertThat(setA, hasItems(s1, s2, "xyz"));
}
@Test
public void mapsUtilityMethods() { 
assertThat(map, hasEntry("a", (Object) 2)); assertThat(map, hasKey("b"));
}
}
The required Hamcrest classes and methods are imported.
Hamcrest allows us to test whether or not a given collection contains specific values.
In the case of maps, Hamcrest provides assertions for entries (key and value) or keys only.
Both libraries also offer an interesting feature – namely, that of searching objects within collections based on their properties. The example below has been written with FEST Fluent Assertions:
Listing 6.47. Testing collections objects by properties
import static org.fest.assertions.Assertions.assertThat;
public class FestTest {
@Test
public void lookingIntoProperties() { Collection<Book> books = new HashSet<Book>(); books.add(new Book("Homer", "Odyssey")); 
books.add(new Book("J.R.R. Tolkien", "Hobbit"));
assertThat(books).onProperty("title").contains("Hobbit"); 
assertThat(books).onProperty("author").contains("J.R.R. Tolkien"); 
assertThat(books).onProperty("author").contains("J.K. Rownling"); 
}
}
A constructor of the Book class sets its two fields - author and title. These two assertions will pass.
This one will fail - my books collection does not include any work by "J.K. Rownling".
Both Hamcrest and FEST offer very detailed and readable error messages. For example, when looking for the String "xyz" in a set of two Strings comprising "s1" and "s2", the following message is printed by Hamcrest:
137