-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Deprecate APIs that use Hamcrest classes. Users should use java-hamcrest #1150
Conversation
First step for resolving #1145 |
fc917be
to
e5c3363
Compare
…amcrest library instead.
e5c3363
to
53d6fc2
Compare
Note if we merge this pull, we'll need to add many methods to |
I think we should deprecate both |
I don't think we should deprecate classes just because they exist in java-hamcest. The question is whether the classes would be useful without the deprecated methods. I don't think we should deprecate I'm less sure about what to do about |
If we won't deprecate |
I think we can say the same about Do you want us to create replacement APIs first? |
Since hamcrest-junit includes Just a thought: Is there a way to allow assertion frameworks (like Truth, AssertJ, or hamcrest-junit) to extend those rules without subclassing? Maybe a new interface interface Check<T> {
void check(T item) throws AssertionError;
} So, at least in Java 8, in Hamcrest this would be thrown.expectMessage(message -> assertThat(message, containsString("foo"))) or in Truth: thrown.expectMessage(message -> assertThat(message).contains("foo"))) |
hamcrest-junit could provide a bit of syntactic sugar for it, something like public class HamcrestCheck<T> implements Check<T> {
private final Matcher<? super T> matcher;
public static final HamcrestCheck<T> doesMatch(Matcher<? super T> matcher) {
return new HamcrestCheck<>(matcher);
}
private HamcrestCheck(Matcher<? super T> matcher) {
this.matcher = matcher;
}
public void check(T item) {
assertThat(item, matcher);
}
} So this can be shortened to (even in Java < 8): thrown.expectMessage(doesMatch(containsString("foo"))); |
Well, the classes were copied from JUnit to hamcrest-junit so people could migrate by just changing imports. So the confusion is unavoidable. I do know projects that use these classes without Hamcrest, so I wouldn't want to remove them. If you think that having these classes have the same name is confusing, then maybe you could ask the Hamcrest team to rename their versions. Truth already supports assumptions and checks (I believe without subclassing our classes):
Perhaps we should ask the Hamcrest team if they would need a If we add a Edit: BTW, I don't think Java 8 users should be using the |
Looking at the code, it needs two features: something that asserts against a given exception (possibly missing), and something to describe what was expected. Could you introduce an interface for these ( There's a second question about whether such a Check interface should be templated. My experience with Java generics has been so painful, that I'd avoid that. Either make it accept |
@sf105 Thanks for joining the conversation, highly appreciated! Doesn't something like thrown.expectMessage(message -> assertThat(message, containsString("foo"))) already solve both problems? It asserts against the exception and describes what was expected. The only part that's missing is that the assertion was about the message of the expected exception. I guess that could be added by We might need to do a few spikes to compare the design possibilities... |
@marcphilipp That's a neat idea. |
@marcphilipp considering that we agreed to have a lambda-friendly exception assertion API in 4.13, I think we are covered for the methods I am deprecating in Do we need to replace these APIs before we deprecate them? |
Thanks, @kcooney! I've decided to merge this pull because we agree that we want to deprecate these APIs. Can you please add a section to the 4.13 release notes? I've opened a new issue to continue the discussion whether we need to provide replacement APIs for methods in |
No description provided.