If someone started preparing a junit5 migration PR they will run into
merge conflicts if everyone now starts replacing these instances at will.
There are also some options on the table on how to actually do the
migration; we can use hamcrest of course, or create a small wrapper in
our test utils that retains the signature junit signature (then we'd
just have to adjust imports).
On 14/07/2021 16:33, Stephan Ewen wrote:
@Chesnay - can you elaborate on this? In the classes I worked with so far,
it was a 1:1 replacement of "org.junit.Assert.assertThat()" to
"org.hamcrest.MatcherAssert.assertThat()".
What other migration should happen there?
On Wed, Jul 14, 2021 at 11:13 AM Chesnay Schepler <ches...@apache.org>
wrote:
It may be better to not do that to ease the migration to junit5, where
we have to address exactly these usages.
On 14/07/2021 09:57, Till Rohrmann wrote:
I actually found
myself recently, whenever touching a test class, replacing Junit's
assertThat with Hamcrest's version which felt quite tedious.
