Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Migrating to JUnit 5

See original GitHub issue

I propose that we start migrating the test suite for Netty 5 (the master branch) to JUnit 5.

JUnit 5 is more expressive, extensible, and composable in many ways, and it’s better able to run tests in parallel. It can also directly run JUnit 4 tests, using the vintage engine, which means we can do this in small steps; there’s no need to migrate all tests all at once.

Once the JUnit 5 infrastructure is there, tests or modules can be migrated one by one, or be left as is for the time being. Regardless, new tests that are only added to the master branch can immediately use the new JUnit 5 test APIs.

Some benefits I anticipate are:

Some tests will become easier to write, because JUnit 5 is more capable at expressing nesting of tests, and parameterisations.
Builds should complete faster because JUnit 5 is better able to run tests in parallel. This is something that needs to be enabled explicitly, however, since it can cause latent test isolation failures to pop up.
JUnit 5 is extensible enough that something like TimedOutTestsListener won’t need to live in the netty-build anymore.

A drawback I can think of is that forward porting changes to a JUnit 4 test in Netty 4.1, to a migrated JUnit 5 test in master, will be more challenging and add to the workload of doing changes in 4.1.

What do people think?