Re: Decoupling JUnit and Hamcrest

Hi,

I'm not a developer of junit nor hamcrest and I don't feel the pain of 
the tight integration of junit and hamcrest that "prevents both from 
moving on" but I'm a heavy user of both.
I don't think it's a good idea to separate the hamcrest integration from 
junit into it's own library.

At the moment JUnit dictates the hamcrest version to be used but also 
guarantees compatibility with this version.
With the new library hamcrest developers will dictate the junit version 
that is compatible with a specific hamcrest release. This is only a 
change in responsibility but has no benefits.

Of course there is also the opportunity to provide a broader range of 
compatible versions. But this opportunity also means more work for the 
maintainers and slower adoption by users. JUnit 4.12 uses hamcrest 1.3. 
What if JUnit moves on to 4.13, 4.14 and hamcrest releases 2.0 and 2.1 
respectively. Will there be a version which is compatible with hamcrest 
2.1 and JUnit 4.13? Will there be a version which is compatible with 
JUnit 4.14 and hamcrest 1.3?

As a developer who want's to use JUnit 4.14 - *how do I know which 
hamcrest-junit-integration version to use? What will stop me from using 
a wrong version?* For example I might be tempted to update JUnit to 4.14 
but forget to update hamcrest-junit-integration. There might be changes 
of the behaviour of JUnit that might cause some of my tests to pass 
always although they should fail. On the other hand: JUnit 4.14 might be 
binary incompatible to JUnit 4.12 - where to look for the right version 
of hamcrest-junit-integration?

If hamcrest moves on to 2.0 - which could be binary incompatible to 1.3 
due to the major version change (haven't checked) - *how long will 
hamcrest 1.3 be supported with latest JUnit versions by 
hamcrest-junit-integration?* I'm asking because we also use JMock which 
depends on hamcrest as well. If I update to an incompatible 2.0 I need 
also an update of JMock....
(( Actually I cannot update JMock without big effort because there was 
an incompatible change from 2.5.1 to 2.6 .... ))

On the other hand this will slow down speed for adoption of new JUnit 
versions because we have to wait until a new hamcrest-junit-integration 
version is out or at least someone has built the appropriate version 
with latest JUnit release and verified unit tests are still passing. It 
will also increase the effort necessary to try JUnit release candidates 
or snapshots in real projects (because I also have to checkout and build 
the integration library myself to be sure there is no problem with 
that... and if there is a problem I need to fix it myself or stop using 
latest JUnit release candidate).

----
IMHO decoupling JUnit and hamcrest has more drawbacks than benefits. 
Although I see it can be a chance for hamcrest to move on. I don't think 
JUnit as a project will profit that much. JUnit users might have a 
broader choice of compatible hamcrest versions but this requires some 
effort (of the maintainers of hamcrest-junit-integration). I think this 
might only work well for JUnit users if the JUnit team commits to that 
integration project and is able to push out new releases of the 
hamcrest-junit-integration together with new JUnit releases.


Regards,
Stefan


Am 07.01.2015 um 08:31 schrieb Stefan Birkner [email protected] 
[junit]:
>
> FYI: Nat Pryce took a first step for decoupling JUnit and Hamcrest:
> http://natpryce.com/articles/000806.html
>
>