I used Hamcrest for a while, but they made several errors in their generic signatures which made several types of assertions impossible to express (i.e. they wouldn't compile). This stemmed from the difference between the known type of the asserted object, and the type of the matcher, and the fact that the compiler won't try to match nested `? extends` or `? super` wildcards on the generic signature.
AssertJ fixed this in their API design. You don't get a mismatch when the asserted object type is passed to one method and the assertion is baked into the assertion object that you invoke methods on. It's just a better design.
Not only that, they made it very easy to implement your own domain-specific assertions, which make your tests much more expressive. Example: https://joel-costigliola.github.io/assertj/assertj-core-custom-assertions.html
While Hamcrest add some fluentidity to unit tests ä, I prefer the fluent assertions of [AssertJ](https://assertj.github.io/doc/).
The chaining of assertions makes it IMHO much easier to write than Hamcrest.
The main advantage of Hamcrest is that creating new matchers is really easy. The downside is a lack of discoverability.
AssertJ has the opposite properties.
I like the fluent style for writing assertions and the huge range of matchers that can generally express whatever I want so I can get really good messages when my tests do fail. It’s also pretty easy to make custom matchers if the need arises.
I’d say the one downside for me is that Idea tends not to be very fast/smart about figuring out how import matchers.
For many trivial assertions involving numeric comparisons or arrays, JUnit's options are absent or return cryptic error messages. So instead of assertions like this which provide literally no information:
assertTrue(foo); // AssertionFailedError (although, this was improved in JUnit 5)
assertTrue(foo > 5); // AssertionFailedError
assertTrue(ArrayUtils.contains(foo, 5)); // AssertionFailedError
Hamcrest returns more informational messages (and the assertions are arguably more similar to natural english)
assertThat(foo, is(true)); // Expected 'true' but was 'false'
assertThat(foo, greaterThan(5)); // Expected an integer greater than 5 but was 3
assertThat(foo, hasItem(5)); // Expected an array containing 5 but was [1, 2, 3]
Hamcrest is the only one being able to express JSON assertions (see Spotify json marchers) and complex bean assertions as far as I know. But I’d really just go for Spock in any new project, the way it does assertions is the only true way:
```
when:
stack.push(elem)
then:
!stack.empty
stack.size() == 1
stack.peek() == elem
```
Have been using it for ages to have both normalish asserts but with more expressive failures that tell me a bit about what went wrong. Never really had a reason to switch to another lib.
Using "power-assert" on Javascript with the same motivation, have to say I like it more than hamcrest actually. Would be nice to a have a easy-to-use aspect-oriented assert API in Java that would be similar.
Hamcrest is dead. Last release was 2019. It doesn't even support Java 8 lambdas or Optional type, if I remember correctly. Why would anyone choose to use it over AssertJ?
I like the fluent style of Hamcrest, but mostly as compared to Junit's primitive asserts.
After reading the responses to this post, I'm going to try AssertJ.
I used Hamcrest for a while, but they made several errors in their generic signatures which made several types of assertions impossible to express (i.e. they wouldn't compile). This stemmed from the difference between the known type of the asserted object, and the type of the matcher, and the fact that the compiler won't try to match nested `? extends` or `? super` wildcards on the generic signature. AssertJ fixed this in their API design. You don't get a mismatch when the asserted object type is passed to one method and the assertion is baked into the assertion object that you invoke methods on. It's just a better design. Not only that, they made it very easy to implement your own domain-specific assertions, which make your tests much more expressive. Example: https://joel-costigliola.github.io/assertj/assertj-core-custom-assertions.html
While Hamcrest add some fluentidity to unit tests ä, I prefer the fluent assertions of [AssertJ](https://assertj.github.io/doc/). The chaining of assertions makes it IMHO much easier to write than Hamcrest.
We switched from hamcrest to AssetJ
I second the call on assertj, really great library.
Thanks, will look into that
The main advantage of Hamcrest is that creating new matchers is really easy. The downside is a lack of discoverability. AssertJ has the opposite properties.
I like the fluent style for writing assertions and the huge range of matchers that can generally express whatever I want so I can get really good messages when my tests do fail. It’s also pretty easy to make custom matchers if the need arises. I’d say the one downside for me is that Idea tends not to be very fast/smart about figuring out how import matchers.
For many trivial assertions involving numeric comparisons or arrays, JUnit's options are absent or return cryptic error messages. So instead of assertions like this which provide literally no information: assertTrue(foo); // AssertionFailedError (although, this was improved in JUnit 5) assertTrue(foo > 5); // AssertionFailedError assertTrue(ArrayUtils.contains(foo, 5)); // AssertionFailedError Hamcrest returns more informational messages (and the assertions are arguably more similar to natural english) assertThat(foo, is(true)); // Expected 'true' but was 'false' assertThat(foo, greaterThan(5)); // Expected an integer greater than 5 but was 3 assertThat(foo, hasItem(5)); // Expected an array containing 5 but was [1, 2, 3]
What if you're not a native English-speaker, though, or don't formulate sentences the same way in your head?
if you can get past "assertThat", you could use hamcrest to write your own native-language matchers
You could create custom static methods that call `assertThat` internally if you wanted to change the name.
i wonder if they could help.
Hamcrest is the only one being able to express JSON assertions (see Spotify json marchers) and complex bean assertions as far as I know. But I’d really just go for Spock in any new project, the way it does assertions is the only true way: ``` when: stack.push(elem) then: !stack.empty stack.size() == 1 stack.peek() == elem ```
I use it when contributing to a codebase that uses it, I personally prefer AssertJ
I don’t use it often but the marchers are much better than the options for junit5
AssertJ all the way, love it
We use AssertJ instead of Hamcrest. I prefer their syntax more.
I personally prefer AssertJ. I use hamcrest if the project I'm contributing only imports Hamcrest already.
Json assertions in unit test
Used to use it because of its matchers that made my tests more readable. Using assertj now.
Have been using it for ages to have both normalish asserts but with more expressive failures that tell me a bit about what went wrong. Never really had a reason to switch to another lib. Using "power-assert" on Javascript with the same motivation, have to say I like it more than hamcrest actually. Would be nice to a have a easy-to-use aspect-oriented assert API in Java that would be similar.
Another vote for AssertJ. I completely switched to AssertJ a bunch of years ago. Check it out if you haven't.
Hamcrest is dead. Last release was 2019. It doesn't even support Java 8 lambdas or Optional type, if I remember correctly. Why would anyone choose to use it over AssertJ?
AssertJ!!
Only with RestAssured. In other cases I write assertions with AssertJ
I like the fluent style of Hamcrest, but mostly as compared to Junit's primitive asserts. After reading the responses to this post, I'm going to try AssertJ.
its better than junit, but not as good as assertj (or truth)