ID | IEP-30 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created | 21.02.2018 | ||||||||
Status |
|
Table of Contents |
---|
...
An extension will be executed only if a class marked the corresponding annotation. For detailed information, please take a look at the tutorial.
Junit5 allows the next annotations in interfaces:
...
And the classes that implement these interface will inherit the test cases.
5 version allows to define custom annotations that act as conditions to determine whether a test should be run or not. It is necessary to create annotation for condition
Code Block |
---|
@Target({ ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@ExtendWith(DisabledOnEnvironmentCondition.class)
public @interface DisabledOnEnvironment {
String[] value();
} |
And class that implements the appropriate interface and override the evaluate() method
Code Block |
---|
@Override
public ConditionEvaluationResult evaluate(TestExtensionContext context) {
// evaluation logic
} |
Now we can add annotation on the test method
Code Block |
---|
@Test
@DisabledOnEnvironment({"dev", "prod"})
void testFail() {
fail("this test fails");
} |
Now it becomes available to define parameters for test constructors and methods and use dependency injection for them. With ParameterResolver class we can resolve parameters in runtime.
At the time of this writing there are 3 built-in parameter resolvers: TestInfo, RepetitionInfo, TestReporter. Example for one of them:
Code Block |
---|
@Test
@DisplayName("Test Get Users")
public void testGetUsersNumberWithInfo(TestInfo testInfo) {
// test logic.
logger.info("Running test method:" + testInfo.getTestMethod().get().getName());
} |
Migration from JUnit 4 to 5 is not so difficult, as backward compatibility is available.
...
...
The community is informed about the migration to 5 and benefits of the newest version.
...
Remove JUnit3TestLegacyAssertclass. Replace inheritance to importsActualize JUnit3TestLegacyAssert class: rename it, update documentation. Replacement inheritance to imports is not appropriate here as it leads to changes of all test classes. Moreover, during migration to the next JUnit versions, problem with changing all test classes will arrise again and in new test classes developer should make import manually.
In JUnit3TestLegacySupport:
Futhermore, GridAbstractTest and GridCommonAbstractTest refactoring necessity should be investigated. Check ability to turn some instance methods to static methods. It was mentioned in the conversation on dev-list.
...