hamcrest
All matchers should implement equals and hashCode methods.
Equals and hashCode methods are in general useless when one uses Hamcrest for testing. But I want to build a library for mocking Apache HttpClient and I plan to build it on top of Hamcrest Matchers. I want to test if my code generates correct set of matchers. Now I need to write:
assertTrue(urlConditions.hostConditions.get(0).matches("localhost"));
but I would prefer to write
assertThat(urlConditions.hostConditions,contains(Matchers.equalTo("localhost")));
to do so Matchers would have to implement equals and hashCode methods.
This would be a big change for an unusual requirement. Can you provide a bit more context for what you think your tests would look like?
Why do you think it is a big change? I see it rather small, equals and hashcode are very simple and can be even generated automatically.
I'm writing a library for mocking Apache HttpClient. It will work similarly to WireMock. A user will be able to write:
httpClient.onPost("http://ww.example.com") .withParameter("foo",equalsTo("abc")) .withRefrence(emptyString()) .doReturn("Example");
Suche a code will generate a set of Matchers. Later when someone executes HTTP request using that client and it matches all Matchers it returns response "Example".
Part of working on the library is testing. I want to check if a generated set of Matchers contains expected ones.
Is this explanation enough?
If you don't mind I could try to implement them on my own.
The effort would be that we would have to enforce it across all the Matchers we've implemented, which is quite a lot. If it was part of the protocol, then other people implementing Matchers would also have to add them. Question, are you generating new Matchers, or just combinations of existing matchers?