Re: Decoupling JUnit and Hamcrest

Thanks for breaking the naming clash, it was getting really confusing. ;-)

@Stefan (cyphoria): I also don’t see concerns about cross version compatibility as the responsibilities of the frameworks are clearly separated and the interfaces between them are very well defined.

@Stephen Connolly: I also like the idea of having another global Error for assumptions and I wonder if it would be possible to integrate such a class in the Java Language. In the meantime, a slim library that provides such an Error as an interface would fit for me. Btw.: AssumptionViolatedError would be a great name, though.

@Marc Philipp:
I totally agree with you: The testing of properties should be done by an assertion framework. I don’t think this should be part of the unit testing framework itself. In my case it was just included because of my playground setup. In a next step, I would extract it like the Hamcrest library. I could think of small libraries that supply such kind of assertion logic for very specific cases that can be used individually or may be bundled together for bigger applications that need almost all kinds of assertions like this.

Concerning the exception handling, I like the JUnit Rule based approach for applications up to Java 7 (without support for lambdas) very well. This provides a way to execute a piece of code and provide information about the code that was executed. In order to be compatible to Java 7 (and maybe 6), I think it is a must-have feature in the next testing framework. Anyways, wherever possible, I would strongly recommend to leave the assertion part out of the test framework and simply provide an extension point (like the @Rule annotation) for 3rd party libraries. For Java 8, I really prefer the lambda approach, as it makes the test code much more readable and expresses the intend of the test case more clearly.

All the best, Stefan


Am 11.01.2015 um 20:27 schrieb [email protected] [junit] <[email protected]>:

> Before there's a StefanOverflowError on this list, I have to step in... ;-)
> 
> Stefan (Bechtold), I strongly agree with most of your points. Although your fluent API looks very elegant, I think testing the properties (e.g. message, cause, and so on) of an exception is something that can and IMHO should also be done using the assertion framework that was chosen by the user. 
> 
> We are currently discussing a very slim approach to state that a block of code is expected to throw an exception of a certain class. If it does not throw an exception of the expected class you'll get an AssertionError. Now, to check the exception message etc. you can use the assertion framework of your choice, e.g. Hamcrest:
> 
> public void test() {
> // setup
> 
> IllegalArgumentException thrown = expect(IllegalArgumentException.class, () -> doSomethingThatThrows());
> 
> //optionally assert something about the exception
> assertThat(thrown, hasMessage(startsWith("foo")));
> }
> 
> For details/feedback please see the full discussion at:
> https://github.com/junit-team/junit/pull/1055
> 
> Cheers,
> 
> Marc
> 
> 



[Non-text portions of this message have been removed]



------------------------------------

------------------------------------