What is the idiomatic Hamcrest pattern to assert that each element of an iterable matches a given matcher?

Question

Examine the following snippet:

    assertThat(         Arrays.asList("1x", "2x", "3x", "4z"),         not(hasItem(not(endsWith("x"))))     ); 

This asserts that the list doesn't have an element that doesn't end with "x". This, of course, is the double negatives way of saying that all elements of the list ends with "x".

Also note that the snippet throws:

java.lang.AssertionError:  Expected: not a collection containing not a string ending with "x"      got: <[1x, 2x, 3x, 4z]> 

This lists the entire list, instead of just the element that doesn't end with "x".

So is there an idiomatic way of:

• Asserting that each element ends with "x" (without double negatives)
• On assertion error, list only those elements that doesn't end with "x"

Answer 1

You are looking for everyItem():

assertThat(     Arrays.asList("1x", "2x", "3x", "4z"),     everyItem(endsWith("x")) ); 

This produces a nice failure message:

Expected: every item is a string ending with "x"      but: an item was "4z" 

Answer 2

The matcher given by David Harkness produces a nice message for the expected part. The message for the actual part, however, is also determined by which assertThat method you use:

The one from JUnit (org.junit.Assert.assertThat) produces the output you provided.

• With the not(hasItem(not(...))) matcher:

  java.lang.AssertionError:  Expected: not a collection containing not a string ending with "x"      got: <[1x, 2x, 3x, 4z]> 

• With the everyItem(...) matcher:

  java.lang.AssertionError:  Expected: every item is a string ending with "x"      got: <[1x, 2x, 3x, 4z]> 

The one from Hamcrest (org.hamcrest.MatcherAssert.assertThat) produces the output given by David:

• With the not(hasItem(not(...))) matcher:

  java.lang.AssertionError:  Expected: not a collection containing not a string ending with "x"      but: was <[1x, 2x, 3x, 4z]> 

• With the everyItem(...) matcher:

  java.lang.AssertionError:  Expected: every item is a string ending with "x"      but: an item was "4z" 

My own experimentation with the Hamcrest assert showed me that the "but" part is often confusing, depending on how exactly multiple matchers are combined and which one fails first, and therefore I still stick to the JUnit assert, where I know quite exactly what I'll see in the "got" part.