Switch from truth to assertj and add junit launcher#310
Conversation
Update from truth to assertj (truth pulls in a JUnit 4 dependency) and use the JUnit 5 BOM and specify the runtime launcher dependency. This should unblock migrating to newer versions of JUnit 5.
| # test | ||
| androidGradlePlugin = "7.3.1" | ||
| assertj = "3.27.2" | ||
| guava = "33.4.8-jre" |
There was a problem hiding this comment.
One test requires Guava and it was pulled in before via truth as a transitive dep.
|
This should unblock #309 and future JUnit updates. |
|
I strongly prefer Truth to AssertJ for personal historical reasons (it's bailed me out of some tricky failed tests with better error messaging), but the usage here isn't so complex that I think we'll fall prey to those problems. If it's a JUnit 4 dependency that's causing the issue, does a transitive exclusion work? I'd also hope to see activity on Truth's issue tracker... |
I could leave out the migration off truth but since it pulled in JUnit 4 I wanted to rule that out and didn't want to mess with exclusions and adding JUnit vintage. I've had good luck with assertj in the past and the fact that it is a lighter dependency footprint is a good tradeoff to me. I think https://github.com/bufbuild/buf-gradle-plugin/pull/310/files#diff-c0dfa6bc7a8685217f70a860145fbdf416d449eaff052fa28352c5cec1a98c06R53 is the fix to allow upgrades. |
andrewparmet
left a comment
andrewparmet
left a comment
There was a problem hiding this comment.
We shouldn't need JUnit vintage since we don't use the JUnit 4 annotations.
I do like Truth's custom Subject technique, but hadn't encountered a need for them yet in this project.
2 participants
Update from truth to assertj (truth pulls in a JUnit 4 dependency) and use the JUnit 5 BOM and specify the runtime launcher dependency. This should unblock migrating to newer versions of JUnit 5.