[Junit-devel] Latest JUnit 4.7 snapshot, includes Hamcrest 1.2

[David S. <da...@sa...>]

The latest snapshot build of 4.7 is junit-4.7-SNAPSHOT-20090601-1258.
This build upgrades the bundled version of Hamcrest up to 1.2, which
has effects on the Matchers used as targets of the assertThat()
statement.  If anyone can try compiling their pre-4.7 code which uses
assertThat against the new build, and can report results, it would be
a great help.  Share and enjoy,

   David Saff

More detailed notes:

- Hamcrest 1.2 is now incorporated.
  - The following methods from `JUnitMatchers` are deprecated, and
moved to `CoreMatchers`:
    - `JUnitMatchers.hasItem` is now `CoreMatchers.hasItem`
    - `JUnitMatchers.hasItems` is now `CoreMatchers.hasItems`
    - `JUnitMatchers.containsString` is now `CoreMatchers.containsString`

  - Matchers now have more informative mismatch descriptions.  For example:

      @SuppressWarnings("unchecked")
	  @Test public void stringIsAnInteger() {
	      assertThat("identifier", "actual", matches(is(Integer.class)));
	      // prints:
	      // Expected: is an instance of java.lang.Integer
	      //      but: \"actual\" is a java.lang.String
      }

  - Some matchers have slightly changed type signatures, especially
those created
    by `is()` and `equalTo`.  Everything should work, except see
`BothTest` for an
    example of how the `both().and()` and `either().or()` constructs may be
    affected.  To essentially disable type-checking for a matcher expression,
    use `JUnitMatchers.matches()` (see below)

  - `JUnitMatchers.isOneOf(...)` is sugar for the situation where you
want to specify
	a finite list of concrete objects that can match.  For example:

	  assertThat(3, isOneOf(3, 4));

  - `JUnitMatchers.matches()` disables type-checking of a matcher entirely.

	 Goofy example:
	
	    assertThat(3, matches(containsString("a")));
	
	 Real example:
	
	    assertThat(3, either(matches(is(String.class))).or(
		                     matches(is(Integer.class))));