Publish to Maven Central as a single JAR file. Do not publish separate hamcrest-api and hamcrest-library JARs.

This will make things easier for client projects and simplify the build.

Hello,

Unit test fail with JDK7. Tested with junit 4.11, Ant 1.8.4 and both OpenJDK 7 and Oracle JDK 7 with the following versions:

% java -version
java version "1.7.0_15"
OpenJDK Runtime Environment (IcedTea7 2.3.7) (ArchLinux build 7.u13_2.3.7-2-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

% java -version
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

Some failing tests and output:

[junit] Testcase: testOnlyReadsPublicStaticAnnotatedMethodsThatReturnNonVoid(org.hamcrest.generator.ReflectiveFactoryReaderTest):   FAILED
[junit] expected:<[g]oodMethod> but was:<[anotherG]oodMethod>
[junit] junit.framework.ComparisonFailure: expected:<[g]oodMethod> but was:<[anotherG]oodMethod>
[junit]     at org.hamcrest.generator.ReflectiveFactoryReaderTest.testOnlyReadsPublicStaticAnnotatedMethodsThatReturnNonVoid(ReflectiveFactoryReaderTest.java:87)

Complete output

[junit] Testcase: testReadsGenerifiedParameterTypes(org.hamcrest.generator.ReflectiveFactoryReaderTest):    FAILED
[junit] expected:<...java.lang.String[]...> but was:<...[Ljava.lang.String;...>
[junit] junit.framework.ComparisonFailure: expected:<...java.lang.String[]...> but was:<...[Ljava.lang.String;...>
[junit]     at org.hamcrest.generator.ReflectiveFactoryReaderTest.testReadsGenerifiedParameterTypes(ReflectiveFactoryReaderTest.java:178)

Complete output

Is JavaHamcrest only compatible with Java 6?

https://gist.github.com/hertzsprung/5141786

Gives me

java.lang.AssertionError: 
Expected: (hasProperty("myBoolean", <true>) and a collection containing "quux")
     but: a collection containing "quux" 

even though the collection was empty.

The source tree is organised into multiple source roots. This makes the build more complicated. Since 7.0 will be released as a single JAR (see #86), there is no need for different source roots.

On use of equalToIgnoringWhiteSpace within is(...) Matcher-Decorator you got an java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V

hamcrest-all, V1.1 works correct

Hi There - Currently, TypeSafeMatcher.match return false if null or the wrong type is passed. I think this is likely to mask bugs in code

• If the wrong type is being passed, it's almost certainly a bug, which is easy to introduce since Matcher.match is not typesafe.
• If null is passed, the Matcher implementation should deal with it - in most cases, this will also be a bug, so throwing a NullPointerException is desirable.

My suggestion for TypeSafeMatcher.match is:

    public final boolean matches(Object item) {
        if (item != null && !expectedType.isAssignableFrom(item.getClass())) {
            throw new RuntimeException("Cannot match " + item.getClass().getName() + " with a type safe matcher for " + expectedType.getName());
        } else {
            return matchesSafely((T) item);
        }
    }

Make sure they're all up to 2015.

Evolution of Hamcrest and JUnit has been held back by the dependencies between the two projects. If they can be decoupled, both projects can move forward with less coordination required.

Plan:

• create a new project (hamcrest-junit, say) that contains a copy of the JUnit code that uses Hamcrest, repackaged somewhere under org.hamcrest (org.hamcrest.junit, say) so that they can live side-by-side with existing JUnit and Hamcrest code.
• Deprecate existing code in JUnit that depends on Hamcrest
• Perhaps deprecate Hamcrest's MatcherAssert class, now that it is duplicated in the hamcrest-junit module.
• Eventually delete the deprecated code.
• Run a CI "matrix" that reports the compatibility of Hamcrest and JUnit versions.

The uses of Hamcrest in JUnit are:

• Assert and Assume in org.junit, for which we'd have to duplicate the methods using matchers as (for instance) MatcherAssert and MatcherAssume
• ErrorCollector and ExpectedException (and a package-protected supporting class) in org.junit.rules, which we'd have to duplicate.
• several classes in the org.junit.internal packages, which client code should not be using

I've seen discussion of this at http://code.google.com/p/hamcrest/issues/detail?id=173 , and the topic has come up in regards to doing the same for Junit (https://github.com/KentBeck/junit/issues/212). Is there any plan for this ?

I'm trying to upgrade to Java 8 and now any assertions using anyOf do not work.

assertThat("hello", anyOf(is("hello"), is("bye")));

I get the message:

The method anyOf(Matcher<capture#1-of ? super String>, Matcher<capture#2-of ? super String>) is undefined for the type TestPushEventMessage

I also tried:

assertThat("hello", anyOf("hello", "bye"));

And get the message:

The method anyOf(Matcher, Matcher<? super T>) in the type Matchers is not applicable for the arguments (String, String)

Depends on #88

The code generation complicates the build. But it's as easy to maintain the generated classes by hand.

We will:

• Bring the generated CoreMatchers and Matchers factory classes into the source
• Delete the codegen
• Remove @factory annotations
• Deprecate the @factory annotation interface (not delete in case client code uses it)

I have a series of matchers that I want to assert, and they must all be true to be successful (all_of). However, when it fails, I really only want the failing one to be the description.

From a ant -Dversion=1.3-redhat-1 bundle (to try to make a bundle to use a
org.hamcrest:hamcrest-core:jar:1.3-redhat that jnr-enxio is requires):

javadoc:
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.hamcrest.generator...
  [javadoc] Loading source files for package org.hamcrest.generator.config...
  [javadoc] Constructing Javadoc information...
  [javadoc] Creating destination directory: "/usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-javadoc.jar.contents/"
  [javadoc] Standard Doclet version 1.8.0_25
  [javadoc] Building tree for all the packages and classes...
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:34: warning: no @throws for java.io.IOException
  [javadoc]     void writeHeader() throws IOException;
  [javadoc]          ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:39: warning: no description for @param
  [javadoc]      * @param generatedMethodName
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:40: warning: no description for @param
  [javadoc]      * @param factoryMethodToDelegateTo
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:42: warning: no @throws for java.io.IOException
  [javadoc]     void writeMethod(String generatedMethodName, FactoryMethod factoryMethodToDelegateTo) throws IOException;
  [javadoc]          ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:47: warning: no @throws for java.io.IOException
  [javadoc]     void writeFooter() throws IOException;
  [javadoc]          ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:38: warning: no @return
  [javadoc]     public String getMatcherClass() {
  [javadoc]                   ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:53: warning: no @return
  [javadoc]     public String getName() {
  [javadoc]                   ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:65: warning: no @return
  [javadoc]     public String getGenerifiedType() {
  [javadoc]                   ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:75: error: invalid entity &ht;
  [javadoc]      * ie. 'public Matcher<...&ht;> blah(THIS, AND, THAT)'
  [javadoc]                                  ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:75: error: bad use of '>'
  [javadoc]      * ie. 'public Matcher<...&ht;> blah(THIS, AND, THAT)'
  [javadoc]                                      ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:77: warning: no @return
  [javadoc]     public List<Parameter> getParameters() {
  [javadoc]                            ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:89: warning: no @return
  [javadoc]     public List<String> getExceptions() {
  [javadoc]                         ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:101: warning: no @return
  [javadoc]     public List<String> getGenericTypeParameters() {
  [javadoc]                         ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:115: warning: no @return
  [javadoc]     public String getJavaDoc() {
  [javadoc]                   ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:9: error: self-closing element not allowed
  [javadoc]  * <p/>
  [javadoc]    ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:9: warning: empty <p> tag
  [javadoc]  * <p/>
  [javadoc]    ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:197: warning: no @return
  [javadoc]         public String getType() {
  [javadoc]                       ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryMethod.java:205: warning: no @return
  [javadoc]         public String getName() {
  [javadoc]                       ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/FactoryWriter.java:15: error: tag not allowed here: <p>
  [javadoc]  * <p/>
  [javadoc]    ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:93: error: self-closing element not allowed
  [javadoc]      * <p/>
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:93: warning: empty <p> tag
  [javadoc]      * <p/>
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:98: error: self-closing element not allowed
  [javadoc]      * <p/>
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:98: warning: empty <p> tag
  [javadoc]      * <p/>
  [javadoc]        ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:101: warning: no @param for javaMethod
  [javadoc]     protected boolean isFactoryMethod(JavaMethod javaMethod) {
  [javadoc]                       ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/QDoxFactoryReader.java:101: warning: no @return
  [javadoc]     protected boolean isFactoryMethod(JavaMethod javaMethod) {
  [javadoc]                       ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGenerator.java:62: error: reference not found
  [javadoc]      * @see ReflectiveFactoryReader
  [javadoc]             ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGenerator.java:87: warning: no @throws for java.io.IOException
  [javadoc]     public void generate() throws IOException {
  [javadoc]                 ^
  [javadoc] /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-sources.jar.contents/org/hamcrest/generator/SugarGen
   11095 14-11-16 20:05:06 -0500 [master]
   pdebuildx-amd64:/usr/local//a�
erator.java:44: error: reference not found
  [javadoc]  * @see ReflectiveFactoryReader
  [javadoc]         ^
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating /usr/local/src/hamcrest-git/build/temp/hamcrest-generator-1.3-redhat-1-javadoc.jar.contents/help-doc.html...
  [javadoc] 8 errors
  [javadoc] 20 warnings

BUILD FAILED
/usr/local/src/hamcrest-git/build.xml:118: The following error occurred while executing this line:
/usr/local/src/hamcrest-git/build.xml:256: Javadoc returned 1

Total time: 49 seconds

Has hamcrest 1.3 and junit 4.11

Code:

Object[] objects = new Object[] {null, null};
assertThat(objects, arrayContaining(null, null));

cause NullPointerException:

java.lang.NullPointerException
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.isMatched(IsIterableContainingInOrder.java:65)
at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.matches(IsIterableContainingInOrder.java:52)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:25)
at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:14)
at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
at org.hamcrest.collection.IsArrayContainingInOrder.matchesSafely(IsArrayContainingInOrder.java:26)
at org.hamcrest.collection.IsArrayContainingInOrder.matchesSafely(IsArrayContainingInOrder.java:15)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:65)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.junit.Assert.assertThat(Assert.java:865)
at org.junit.Assert.assertThat(Assert.java:832)

public class HasItemTest {
    @Test public void hasItemTest() {
        Collection<String> collection = new ArrayList<String>();
        assertThat(collection, hasItem(equalTo("foo")));
    }
}

Gives the diagnostics

Expected: a collection containing "foo"
     but: 

Could we add something like but: was empty?

IsIterableContainingInAnyOrder tries to describe the mismatch like this in Matching.isMatched, thus relying on toString:

    mismatchDescription.appendText("Not matched: ").appendValue(item);

Rather it should use the same approach as IsIterableContainingInOrder and use the offending matcher to describe the mismatch. Here is what the IsIterableContainingInOrder Matcher does:

if (!matcher.matches(item)) {
    describeMismatch(matcher, item);
    return false;
}

The description of the org.hamcrest.text.StringContainsInOrder
stringContainsInOrder method is incorrect, and states that the matcher matches regardless of the order of apperance, but in fact it does check the order of apperance (as the method name suggests).

Additionally the example given doesn't help the matter either, by simplying indicating that the example would pass or fail would be useful.

The overloaded methods were written to reduce compile warnings in client code. The @SafeVarargs annotation that was introduced in Java 7 suppresses them altogether.

This will change the ABI, but code will still be source compatible.

When we've reinstated the directory of add-on projects (issue #77), add a link to the chainable matchers in https://github.com/EZGames/ez-testing

Current Javadoc is:

• Creates a matcher that matches when the examined object is equal to one of the
• specified elements.
• For example:

• assertThat("foo", isIn("bar", "foo"))

• @param elements

• the elements amongst which matching items will be found
  

  */
  public static org.hamcrest.Matcher isOneOf(T... elements) {
  return org.hamcrest.collection.IsIn.isOneOf(elements);
  }

But should be:

• Creates a matcher that matches when the examined object is equal to one of the
• specified elements.
• For example:

• assertThat("foo", isOneOf("bar", "foo"))

• @param elements

• the elements amongst which matching items will be found
  

  */
  public static org.hamcrest.Matcher isOneOf(T... elements) {
  return org.hamcrest.collection.IsIn.isOneOf(elements);
  }

CoreMatchers and Matchers are now in the source and both compiled into the same JAR. CoreMatchers is therefore redundant. Matchers is growing larger and larger, to the point that autocomplete in the IDE is awkward.

Therefore,

• Split CoreMatchers and Matchers into domain-specific classes. E.g. ListMatchers, MapMatchers, StringMatchers, NumberMatchers, etc.
• At a later date, we will deprecate Matchers and CoreMatchers and eventually delete them.

It would be nice to have a varargs method for Matchers.stringContainsInOrder, so that instead of:

stringContainsInOrder(Arrays.asList("The", "trio", "arts"))

you can do:

stringContainsInOrder("The", "trio", "arts"))

Right now, the code generator collects factory methods via reflection, which requires the compiled classes of the project to be on the classpath. Then, QDox is used to add more information (e.g., javadocs). Thus, the build process is like [compile, generate, compile].

This process could be simplified by using QDox to search for factory methods. This way, the classes don't have to be compiled before code generation and the build process is only [generate, compile].

The benefit is a simplified build process (cleaner, faster, easier to set up). Also, it is possible now to use the generated class right in the project.

Hi!
When I'm changing hamcrest version from 1.1 to 1.2 (or later) I get
java.lang.NoSuchMethodError: org.hamcrest.core.AllOf.allOf(Lorg/hamcrest/Matcher;Lorg/hamcrest/Matcher;)Lorg/hamcrest/Matcher;

It just looks like the same exception as issue 25.

code:

    @Test
    public void testHamcrest() throws Exception {
        List<Integer> list = Arrays.asList(null, null);
        assertThat(list, IsIterableContainingInOrder.contains(null, null));
    }

output:

java.lang.NullPointerException
    at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.isMatched(IsIterableContainingInOrder.java:65)
    at org.hamcrest.collection.IsIterableContainingInOrder$MatchSeries.matches(IsIterableContainingInOrder.java:52)
    at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:25)
    at org.hamcrest.collection.IsIterableContainingInOrder.matchesSafely(IsIterableContainingInOrder.java:14)
    at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosingMatcher.java:55)
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
    at org.junit.Assert.assertThat(Assert.java:865)
    at org.junit.Assert.assertThat(Assert.java:832)

Trying to use jsonpath 1.1.0 (in conjunction with Spring MVC Test 4.1.0) results in the following:

java.lang.NoSuchMethodError: com.jayway.jsonpath.JsonPath.compile(Ljava/lang/String;[Lcom/jayway/jsonpath/Filter;)Lcom/jayway/jsonpath/JsonPath;
    at org.springframework.test.util.JsonPathExpectationsHelper.<init>(JsonPathExpectationsHelper.java:54)
    at org.springframework.test.web.servlet.result.JsonPathResultMatchers.<init>(JsonPathResultMatchers.java:43)
    at org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath(MockMvcResultMatchers.java:183)
    at id.co.bippo.product.rs.ProductControllerTest.showProduct(ProductControllerTest.java:63)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:72)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:81)
    at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:216)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:82)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:60)
    at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:67)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:162)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

See http://ggl-consulting.blogspot.com/2014/10/hamcrest-library-13-not-compatible-with.html

Junit 4.11 includes that assertThat() that reports mismatches

While IsMapWithSize exists in the API to test for these conditions on a Map, they are hard to find. Most developers only use the Matchers facade to find matchers, so we end up with code that looks like this:

assertThat(aMap.entrySet(), Matchers,empty())

It would be nicer to write:

assertThat(aMap, Matchers.empty())

Currently, equalTo() will not compile when comparing Object to another class forcing unnecessary casting. For example:

HttpServletRequest request = (get request);
Object actual = request.getAttribute("SomeAttribute");
assertThat(actual, equalTo((Object) fooInstance));

In this example, the compile will fail unless fooInstance is cast to Object. But this is unnecessary for equals() to work correctly.

If the signature of equalsTo() were:

Matcher<Object> equalTo(Object o)

it could avoid the above problem.

I have noticed that there are a few people using FEST-Assert instead of Hamcrest. After looking at it a bit it is really just syntactic sugar. Would it make sense to add something similar into Hamcrest so that people can use the syntax they like but still leverage the Matcher implementations. The FEST-Assert Condition class looks like a Matcher to me.

Any thoughts?

assertThat(Double.POSITIVE_INFINITY, closeTo(Double.POSITIVE_INFINITY, anyDouble)) should probably pass, but it fails. Same for Double.NEGATIVE_INFINITY and Double.NaN. A simple solution is to first check for equality.

The following assertion never evaluate to true:

assertThat(null, either(equalTo(something)).or(nullValue()))

The root cause lies in the CombinableMatcher being a TypeSafeDiagnosingMatcher which implements matches() as:

public final boolean matches(Object item) {
    return item != null
        && expectedType.isInstance(item)
        && matchesSafely((T) item, new Description.NullDescription());
}

Thus for null the matchers will never be queried. I suppose the solution should be something like:

public final boolean matches(Object item) {
    return (item == null || expectedType.isInstance(item))
        && matchesSafely((T) item, new Description.NullDescription());
}

I build all of my Java dependencies from source, and JavaHamcrest's use of qdox to generate CoreMatchers is a bit of a roadblock for me: qdox requires jflex to build, and jflex requires cup, which requires jflex. qdox also requires byacc to build. Anyway, it's a nest of circular build dependencies.

Why version CoreMatchers.java, despite being generated code?
(a) qdox is very hard to build without running binaries, as mentioned
(b) it's short and suitable for human review
(c) it's suitable for human modification without using qdox, in dire situations

Right now I'm copying CoreMatchers.java from a src jar and manually keeping it up to date.

Thanks for your consideration.

There's a Hamcrest-Extras library that has matchers for Guava's Optional. It would be cool to have the standard Hamcrest library provide these kinds of matchers for the pure JDK 8 Optionals as well.

Are there other than me that would like to see a simple String length matcher in the core library for the upcoming release?

It was requested already more than a year ago, here https://code.google.com/p/hamcrest/issues/detail?id=191

(Please, let me know if I can help out in any way?)

see original post:
https://code.google.com/p/hamcrest/issues/detail?id=205&sort=-id

i really would like to contribute that piece of code to the official project :)

kr,
christoph

There have been a number of changes since hamcrest-java-1.3 was released in 2012 and, for people who use Hamcrest's binary releases, it would be good to get them into a public 1.4 release.

There was some discussion on the mailing list back in 2013 about a Java Hamcrest 1.4 Release Plan, which suggested that #32 was the blocker for a release. However, discussion on that pull request now implies that a new release is unlikely.

A new release would be a great resolution for this, but it would also be good to have some expectation-setting, so users can decide whether waiting, making their own releases, or forking would be their best option for getting a current Hamcrest build, or if there's any way to help out.

issue tracker
Readme and JavaHamcrest page

public static org.hamcrest.Matcher isA(java.lang.Class type) {
return org.hamcrest.core.Is.isA(type);
}

means you have to cast the thing to the type you are asserting it should be. Really it should be a matcher of anything (Object) not T.

e.g.
class hierarchy Foo extends Bar

Bar thing = somemethod();
assertThat(thing, isA(Foo.class))

to assert that you are getting the right subclass back - yeah ok, it might not be the best test, but anyhow......

It seems that everyItem() uses shortcut logic, i.e. stops diagnosis at the first mismatch.

Whilst possibly the best idea in the general case, it's painful if you have to keep re-running the test to find out what "the next problem" is in the collection - c.f. HTML form validation in the early days of the web.

Interestingly, hasItem() (conceptually quite similar) does diagnose all the mismatches in the collection passed in. It would be good if these two approaches to a similar problem in the core package were the same / closer.

As it happens, hasItem() also describes itself differently in failed assertions... anyway since a test is worth a thousand words, or something:

package org.hamcrest.core;

import org.hamcrest.Matcher;
import org.junit.Test;

import java.util.ArrayList;

import static java.util.Arrays.asList;
import static org.hamcrest.AbstractMatcherTest.*;
import static org.hamcrest.core.Every.everyItem;
import static org.hamcrest.core.IsCollectionContaining.hasItem;
import static org.hamcrest.core.StringStartsWith.startsWith;

// Test is JDK 7+
public class EveryVsIsCollectionContainingTest {
    public static final Matcher<String> TEXT_MATCHER = startsWith("a");
    public static final Iterable<String> ITEMS = asList("b", "c");
    public static final ArrayList<String> EMPTY = new ArrayList<String>();

    @Test
    public void descriptionsAreDifferent() {
        // <T> Matcher<Iterable<? super T>>
        assertDescription("a collection containing a string starting with \"a\"", hasItem(TEXT_MATCHER));
        // <U> Matcher<Iterable<? extends U>>
        assertDescription("every item is a string starting with \"a\"", everyItem(TEXT_MATCHER));
    }

    @Test
    public void mismatchesAreDifferent() {
        assertMismatchDescription("mismatches were: [was \"b\", was \"c\"]",
                                  hasItem(TEXT_MATCHER), ITEMS);
        assertMismatchDescription("an item was \"b\"", everyItem(TEXT_MATCHER), ITEMS);
    }

    @Test
    public void emptyBehaviourIsDifferent() {
        // Seems "correct", but still a bit confusing.
        assertDoesNotMatch(hasItem(TEXT_MATCHER), EMPTY);
        assertMatches(everyItem(TEXT_MATCHER), EMPTY);
    }
}

I cannot find any class allowing me to write my tests like:

String actual = tested.buildUrlWithRandomPort("foo", "bar");
assertThat(actual, matchesRegex("^foo://bar:\\d+/$");
// fails with a message like:
// expected <foo://bar:/> to match a regular expression <^foo://bar:\d+/$>

I think that Hamcrest Library should offer matchesReges() together with containsString(), endsWith() and startsWith().

Is there a matcher like this available in the master branch? If not, I could write one (something similar to Hamcrest Regex Matcher) and create a pull request.

For example, the description for assertThat(2.2, closeTo(3.3, 0.5) ends in "<2.2> differed by <0.6>", but should end in "<2.2> differed by <1.1>". That is, unless I'm misinterpreting the intended meaning of the message.

Correct me if I'm wrong, but there is no easy way to assert that an object is an empty map.

I think we need a matcher similar to IsArrayWithSize from org.hamcrest.collection, offering methods like mapWithSize() and emptyMap().

If you confirm there is no such matcher available, I could implement it and offer a pull request.

isA() method currently accepts parameter of type Class<T> instead of Class<?>.

The following example fails to compile:

Object cheese = new Cheddar();
assertThat(cheese, isA(Cheddar.class));

while one with instanceOf() succeeds:

Object cheese = new Cheddar();
assertThat(cheese, is(instanceOf(Cheddar.class)));

The Is matcher doesn't do anything, and so should be deleted.

Factory methods for is should not be added to the domain-specific factory classes introduced as part of #85

Id like to be able to use the reflective type finder on any Matcher (to help with porting jmock to java 7). If we add a T argument to the dont_implement method on the Matcher interface then the type will be accessible.

In the move from Google Code to GitHub we've lost the directory of add-on libraries.

The factory method Every.everyItem currently returns a Matcher<Iterable<U>>. Wouldn't a Matcher<Iterable<? extends U>> make sense here? This would be in accordance with the guidelines for wildcard use.

Other collection matchers, such as IsIterableContainingInOrder already do this.

Why the JavaHamcrest is not built on Maven POM files?
I guess the committers would have easier life, and it is bulletproof to deploy Maven artifacts to the Maven central repository. Some features could be maybe already accepted if the Maven build was established.