Migrating from JUnit 4 to JUnit 5

[baierd]

Migrating to JUnit 5 would increase the flexibility and introduce the new features of JUnit 5 to our tests while allowing backwards compatibility with JUnit 4.

[baierd]

Just a quick update on the topic: I don't think its a good time to migrate just yet because some features are not yet supported by JUnit 5. Most importantly the ability to use @BeforeEach and @AfterEach (former @Before and @After in JUnit 4) together with parameterized tests yet. I tried a few things as there are some workarounds (hacks) to make it work but they have drawbacks like i.e. the classes need to be static. Of course it would be possible to simply add the methods initSolver() and closeSolver() in every test and remove that once it it possible to use the annotations, but that seems like a lot of work for something that might be added till we need to migrate.

@kfriedberger thoughts?

[kfriedberger]

As most of our tests are parameterized with the solver instance itself, the required code changes are quite high here. Nearly every method needs to be injected with parameters. I agree that we should wait for now, until a better solution for parameterized classes has been found. However, if JUnit5 never gets support for parameterized classes, we need to discuss this issue again.

[baierd]

They state that they want to add it "soon" so we should just monitor the situation.

[PhilippWendler]

I just stumbled over Google's TestParameterInjector, which is an alternative to JUnit's parameterized tests and supports JUnit 5. It actually seems nicer than JUnit's feature because you can for example just declare a boolean field and an enum field and it will run the tests for all combinations without one having to write the cartesian product manually.

For JavaSMT the difficulty is that at least SolverBasedTest0 is de facto part of the public API (it is used by other projects) and of course a switch would be backwards incompatible.