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> 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.
