Upgrade the tests in the reflect package to use JUnit Jupiter as
part of the effort to remove the dependency on the Vintage Engine.
While most of these changes are drop-in replacements with no functional
benefit, there are some non-obvious changes worth mentioning.
Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an
"expected" argument. Instead, an explicit call to
org.junit.jupiter.api.Assertions.assertThrows is used.
Unlike org.junit.Assume, org.junit.jupiter.api.Assumptions does not have
an assumtNotNull method. Instead, assumeTrue was used with an explicit
condition of a variable being different than null.
It's also worth noting this is a minimal patch for migrating the
package's tests to Jupiter. There are several tests that can be made
more elegant with Jupiter's new features, but that work is left for
subsequent patches.
Upgrade the tests in the exception package to use JUnit Jupiter as
part of the effort to remove the dependency on the Vintage Engine.
While most of these changes are drop-in replacements with no functional
benefit, there are some non-obvious changes worth mentioning.
Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an
"expected" argument. Instead, an explicit call to
org.junit.jupiter.api.Assertions.assertThrows is used.
Another non-obvious change was performed in
ContextedRuntimeExceptionTest. Unlike JUnit Vintages's @Before, JUnit
Jupiter's @BeforeEach does not apply if a parent's method is annotated
with it and the overriding method is not, so an explicit @BeforeEach
annotation had to be added to ContexedTuntimeExceptionTest#setUp().
It's also worth noting this is a minimal patch for migrating the
package's tests to Jupiter. There are several tests that can be made
made more elegant with Jupiter's new features, but that work is left
for subsequent patches.
Upgrade the tests in the event package to use JUnit Jupiter as
part of the effort to remove the dependency on the Vintage Engine.
While most of these changes are drop-in replacements with no functional
benefit, it is worth noting the tests that test thrown excetpions.
Prior to this patch, this package tested for exceptions in two ways,
neither of which are supported in JUnit Jupiter:
1. With the "expected" argument of the org.junit.Test annotation.
2. With the org.junit.rules.ExpectedException @Rule
Both of these usages were replaced with calls to
org.junit.jupiter.api.Assertions#assertThrows.
Upgrade the tests in the concurrent package to use JUnit Jupiter as
part of the effort to remove the dependency on the Vintage Engine.
While most of these changes are drop-in replacements with no functional
benefit, there are some non-obvious changes worth mentioning.
Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an
"expected" argument. Instead, an explicit call to
org.junit.jupiter.api.Assertions.assertThrows is used. This call allows
the test to pinpoint the exact statement that is expected to throw the
exception and allows making the tests a bit stricter by preventing
false-positives that could occur if the setup code would throw the
expected exception instead of the statement that was supposed to throw
it.
Another notable change was performed in MemoizerTest.
JUnit Jupiter does not support JUnit 4's runners, and EasyMock has no
equivalent @Extension, so a setup method was added and the mock was
explicitly initialized.
It's also worth noting this is a minimal patch for migrating the
package's tests to Jupiter. There are several tests that can be made
made more elegant with Jupiter's new features, but that work is left
for subsequent patches.
Upgrade the tests in the builder package to use JUnit Jupiter as part of
the effort to remove the dependency on the Vintage Engine.
While most of these changes are drop-in replacements with no functional
benefit, it is worth mentioning the change to how expected exceptions
are tested.
Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an
"expected" argument. Instead, an explicit call to
org.junit.jupiter.api.Assertions.assertThrows is used. This call allows
the test to pinpoint the exact statement that is expected to throw the
expcetion and allows making the tests a bit stricter by preventing
false-positives that could occur if the setup code would throw the
expected exception instead of the statement that was supposed to throw
it.