With regards to JUnit 5, there was a specific proposal and vote on how to deal with that migration [1]
Best regards, Martijn [1] https://lists.apache.org/thread.html/r89a2675bce01ccfdcfc47f2b0af6ef1afdbe4bad96d8c679cf68825e%40%3Cdev.flink.apache.org%3E On Wed, 14 Jul 2021 at 17:31, Chesnay Schepler <ches...@apache.org> wrote: > 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. > >> > >> > >
