> > If someone started preparing a junit5 migration PR they will run into > merge conflicts if everyone now starts replacing these instances at will.
This sounds like a good case for fixing it in one step during the upgrade. Otherwise folks will start individually fixing this individually when they encounter the deprecated methods. On Wed, Jul 14, 2021 at 5:31 PM 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. > >> > >> > >
