hamcrest/hamcrest-junit

Integration between Hamcrest and JUnit

hamcrest-junit's Issues

Future of JUnitMatchers

Almost all factory methods in JUnitMatchers delegate to CoreMatchers from java-hamcrest. There are two matchers left for Throwables (isThrowable and isException) that are not part of hamcrest. The last code usage inside hamcrest-java of JUnitMatchers is removed in #13. There are JavaDoc references in Assume that could easily be changed say that people should use the matchers from java-hamcrest.
I think those two matchers should be moved to hamcrest and JUnitMatchers should be deleted or at least those matchers that only delegate to CoreMatchers should be removed.

ExpectedException#expect() should take Matcher<? extends Throwable> as its argument

This is a "re-post" of an issue originally opened at Junit: junit-team/junit4#610. As JUnit is going to depreciate and eventually remove ExpectedException I'm re-raising it hear in order to start a discussion whether this change should be made:

Consider the following test:

public class WrongUsageOfExpectedExceptionApi {
    @Rule
    public ExpectedException thrown = ExpectedException.none();

    @Test
    public void wrongUsageOfExpectedExceptionApi() throws Exception {
        thrown.expect(RuntimeException.class);

        // thrown.expectMessage() should be used here
        // because an exception cannot start with a string
        thrown.expect(startsWith("some message"));
        throw new RuntimeException("some message");
    }
}
...

When you have something like this in a test it can be quite hard to figure out why the test fails.
At the moment ExpectedException#expect takes a Matcher<?> as its argument. By changing it to take only arguments of the type Matcher<? extends Throwable> the compiler could spot the mistake in the test given above.
I tried the code changes needed for the suggested change in the API with the current master (92a3f73) and all tests pass.
I understand that these changes break the API and non-generic Matchers won't work with the new signature of the method but is there any other reason not to have ExpectedException#expect only take arguments of the type Matcher<? extends Throwable>?
Apart from the exclusion of non-generic Matchers the only downside I see is that now you have to specify the generic type: That is you have to write for example

ExpectedException#expect(CoreMatchers.<Throwable>not(CoreMatchers.<Throwable>instanceOf(type)));

instead of

ExpectedException#expect(not(instanceOf(type)));

Switch to Gradle 2.4

The Eclipse Gradle tooling does not support Gradle 2.0 which is currently used in gradlew for Hamcrest. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=468952

Would it possible for you to switch to Gradle 2.4?

The future of ErrorCollector and ExpectedException

JUnit 4.13 is going to deprecate all APIs that use Hamcrest. This includes methods of both ErrorCollector and ExpectedException. Instead JUnit 5.0 will change the internal implementation to not use Hamcrest.

I'm looking for a way for Hamcrest to be able to extend both rules, e.g. add a expect(Matcher<? super Throwable>) method to ExpectedException or checkThat(T value, Matcher<? super T> matcher). Right now, all I can think of is hamcrest-junit providing subclasses for both rules or JUnit adding a functional interface, e.g. interface Check<T>{ void check(T value) throws AssertionError; }, instead of using Matcher<T> and hamcrest-junit adding an adapter, e.g. MatcherCheck<T> extends Check<T>.

Some of this has already been discussed over at junit-team/junit4#1150

@npryce @sf105 I'm looking for your opinion on this.

hamcrest-junit 2.0.0.0 does not work with JDK 6

The same issue as hamcrest/JavaHamcrest#105 is also present in hamcrest-junit 2.0.0.0.

Please use ErrorCollector from JUnit 4.12

In JUnit 4.12 junit-team/junit4@60aaf96 has made checkSucceeds generic.

Please use this version for hamcrest-junit:
https://github.com/junit-team/junit/blob/r4.12/src/main/java/org/junit/rules/ErrorCollector.java

Declare runtime dependency on JUnit and Hamcrest, not compile dependency

This makes dependency management in client code easier.

License should be EPL

JUnit is licensed under EPL as of 4.12.

See https://github.com/junit-team/junit/blob/master/LICENSE-junit.txt

Use Hamcrest 2.1?

I am having javac warnings such as "unchecked generics array creation" that are long fixed in hamcrest java. As a workaround, I exchanged the hamcrest version in my POM for now. There seem to be no problem at all, changing the version in the gradle build here also lead to no problem. As the 2.0.0.0 version is now untagged anyway, hamcrest-junit can maybe make a 2.1 release that directly uses 2.1?

Release notes

I'm trying to find the release notes for the 2.0.0 release. Where are they stored?

I'm an Eclipse IDE Open Source developer and if the 2.0.0 release has something useful for us, I would like to integrated it for our tests.

@Factory annotation of Hamcrest is missing

This project is missing the org.hamcrest.Factory annotation. Is this going to be added?