Migrate Hamcrest Matchers to AssertJ Assertions#355
Conversation
|
@timtebeek I notice this is still in draft. I take it that means it isn't ready for review yet? |
A full review is probably too early indeed, but any critique of the general approach is much appreciated at this early stage, such that we don't spent effort building the wrong thing potentially. |
And limitations that don't yet work
|
This already migrates some ~50 Hamcrest Matchers. I suggest we pick up any further work separately in #357 |
|
Nice work, it looks good to me! |
joanvr
left a comment
There was a problem hiding this comment.
LGTM from a code style perspective :)
|
Thanks both! Then I'll merge and try it out on the platform when I get back Monday. |
|
@timtebeek Did you try to cover all Hamcrest matchers or only a specific subset? It looks like the I didn't compare the lists in detail. |
|
I'd mostly covered those for strings, objects and collections. There's indeed likely more matches that we could quite easily covered, and more complex recipes that require more work. We can track these in #357 |
What's changed?
Add a generic recipe to replace Hamcrest Matchers with AssertJ Assertions.
What's your motivation?
Hamcrest has not been released in a long time, whereas AssertJ is more actively maintained.
#212
Anything in particular you'd like reviewers to focus on?
If there's any additional matchers we can replace, or argument number corner cases missed.
Anyone you would like to review specifically?
@knutwannheden @kunli2
Have you considered any alternatives or workarounds?
I'd assume it's easier to do it this way rather than go for Java templates for match & replacement, since there's less code to maintain this way and this way there's no templates that depend on multiple libraries. We can still use templates for the more complicated cases.
Any additional context
Similar to #343 ; this is mostly to demonstrate the Yaml recipes I had intended there.
Checklist
./gradlew licenseFormat