I was referring to the proposal to migrate all existing tests to JUnit 5 via one giant commit (as stated in step 3 from the voting email in the link I sent)
On Wed, 14 Jul 2021 at 19:20, Chesnay Schepler <ches...@apache.org> wrote: > I don't believe this case was *explicitly *addressed in either the vote > or discussion thread. Please link the specific post if it was indeed > mentioned. > > On 14/07/2021 19:13, Martijn Visser wrote: > > 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> > <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> > <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. > > >
