Decouple the evolution of Hamcrest and JUnit

[npryce]

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

[npryce]

Repo created at https://github.com/hamcrest/hamcrest-junit

[npryce]

I've copied the JUnit code that depends on Hamcrest and Hamcrest library code that depends on JUnit here: https://github.com/hamcrest/hamcrest-junit and repackaged into org.hamcrest.junit.

I've made the tests pass and set up a Travis CI build here: https://travis-ci.org/hamcrest/hamcrest-junit

I've ensured that the hamcrest-junit code does not pass Hamcrest types to JUnit, so that JUnit can break its dependency on Hamcrest some time in the future.

[npryce]

Still to do - publish to Maven central

[SamirTalwar]

I'm not sure if this is in scope, but I figured it's worth writing down somewhere.

Currently, MatcherAssert.assertThat throws a java.lang.AssertionError on failure with the description built by the matcher. This description can sometimes get pretty massive. By contrast, Assert.assertEquals throws an org.junit.ComparisonFailure, which is a subclass of AssertionError that conveys more information that allows an IDE or something like it to display a diff of the expected and actual results.

Using this sort of thing would be incredibly useful in Hamcrest. However, it's in the JUnit JAR and package structure, not Hamcrest's. Would it be worth creating something like it in hamcrest-junit so that the behaviour (specifically, diffs in the IDE) can be shared between both projects?

[npryce]

That's a good idea but I'm not sure how to do it. AssertThat doesn't see
the expected value, only Matchers that define expected aspects of the
actual value.

It's definitely out of scope for the first release but if you submit a PR
to the hamcrest-junit project we can include it in a later release.

On Wednesday, December 31, 2014, Samir Talwar notifications@github.com
wrote:

I'm not sure if this is in scope, but I figured it's worth writing down
somewhere.

Currently, MatcherAssert.assertThat throws a java.lang.AssertionError on
failure with the description built by the matcher. This description can
sometimes get pretty massive. By contrast, Assert.assertEquals throws an
org.junit.ComparisonFailure, which is a subclass of AssertionError that
conveys more information that allows an IDE or something like it to display
a diff of the expected and actual results.

Using this sort of thing would be incredibly useful in Hamcrest. However,
it's in the JUnit JAR and package structure, not Hamcrest's. Would it be
worth creating something like it in hamcrest-junit so that the behaviour
(specifically, diffs in the IDE) can be shared between both projects?

—
Reply to this email directly or view it on GitHub
#92 (comment)
.

[SamirTalwar]

Sounds reasonable. Will do soon-ish.

[SamirTalwar]

Are you expecting that the code in org.junit.internal will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit?

[sf105]

Junit should be free of hamcrest at some point. Some of that will be achieved by moving stuff into hamcrest-junit

S

Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections.

On 31 Dec 2014, at 12:04, Samir Talwar notifications@github.com wrote:

Are you expecting that the code in org.junit.internal will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit?

—
Reply to this email directly or view it on GitHub.

[npryce]

@SamirTalwar - Code in org.junit.internal will have to be rewritten to remove references to Hamcrest. We're not doing anything about internal JUnit implementation details.