Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The future of ErrorCollector and ExpectedException #11

Open
marcphilipp opened this issue Jun 14, 2015 · 0 comments
Open

The future of ErrorCollector and ExpectedException #11

marcphilipp opened this issue Jun 14, 2015 · 0 comments

Comments

@marcphilipp
Copy link

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.

@marcphilipp marcphilipp changed the title The future for ErrorCollector and ExpectedException The future of ErrorCollector and ExpectedException Jun 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant