Deprecate for removal JUnit 3 and 4 support

Author: filiphr

docs/docusaurus/docs/bpmn/ch04-API.md

@@ -342,13 +342,13 @@ Additionally, it’s possible to register custom functions that can be used in e
 
 Business processes are an integral part of software projects and they should be tested in the same way normal application logic is tested: with unit tests. Since Flowable is an embeddable Java engine, writing unit tests for business processes is as simple as writing regular unit tests.
 
-Flowable supports JUnit versions 3, 4 and 5 styles of unit testing.
+Flowable supports JUnit Jupiter styles of unit testing.
 
-In the JUnit 5 style one needs to use the org.flowable.engine.test.FlowableTest annotation or register the org.flowable.engine.test.FlowableExtension manually.
-The FlowableTest annotation is just a meta annotation and the does the registration of the FlowableExtension (i.e. it does @ExtendWith(FlowableExtension.class)).
+In the JUnit Jupiter style one needs to use the org.flowable.engine.test.FlowableTest annotation or register the org.flowable.engine.test.FlowableExtension manually.
+The FlowableTest annotation is just a meta-annotation and does the registration of the FlowableExtension (i.e., it does @ExtendWith(FlowableExtension.class)).
 This will make the ProcessEngine and the services available as parameters into the test and lifecycle methods (@BeforeAll, @BeforeEach, @AfterEach, @AfterAll).
 Before each test the processEngine will be initialized by default with the flowable.cfg.xml resource on the classpath.
-In order to specify a different configuration file the org.flowable.engine.test.ConfigurationResource annotation needs to be used (see second example).
+To specify a different configuration file, the org.flowable.engine.test.ConfigurationResource annotation needs to be used (see second example).
 Process engines are cached statically over multiple unit tests when the configuration resource is the same.
 
 By using FlowableExtension, you can annotate test methods with org.flowable.engine.test.Deployment.
@@ -357,9 +357,9 @@ In case there are no resources defined, a resource file of the form testClassNam
 At the end of the test, the deployment will be deleted, including all related process instances, tasks, and so on.
 See the Deployment class for more information.
 
-Taking all that in account, a JUnit 5 test looks as follows:
+Taking all that into account, a JUnit Jupiter test looks as follows:
 
-**JUnit 5 test with default resource.**
+**JUnit Jupiter test with default resource.**
 
     @FlowableTest
     class MyBusinessProcessTest {
@@ -388,9 +388,9 @@ Taking all that in account, a JUnit 5 test looks as follows:
       }
     }
 
-    With JUnit 5 you can also inject the id of the deployment (with +org.flowable.engine.test.DeploymentId+_) into your test and lifecycle methods.
+    With JUnit Jupiter you can also inject the id of the deployment (with +org.flowable.engine.test.DeploymentId+_) into your test and lifecycle methods.
 
-**JUnit 5 test with a custom resource file.**
+**JUnit Jupiter test with a custom resource file.**
 
     @FlowableTest
     @ConfigurationResource("flowable.custom.cfg.xml")
@@ -420,55 +420,6 @@ Taking all that in account, a JUnit 5 test looks as follows:
       }
     }
 
-In the JUnit 3 style, the org.flowable.engine.test.FlowableTestCase must be extended. This will make the ProcessEngine and the services available through protected member fields. In the setup() of the test, the processEngine will be initialized by default with the flowable.cfg.xml resource on the classpath. To specify a different configuration file, override the *getConfigurationResource()* method. Process engines are cached statically over multiple unit tests when the configuration resource is the same.
-
-As with the FlowableExtension (see above), extending the FlowableTestCase will enable the use of the org.flowable.engine.test.Deployment annotation (see above for an explanation of its use and configuration). Before the test is run, a resource file of the form testClassName.testMethod.bpmn20.xml in the same package as the test class, will be deployed. At the end of the test, the deployment will be deleted, including all related process instances, tasks, and so on. The Deployment annotation also supports setting the resource location explicitly. See the class itself for more information.
-
-Taking all that in account, a JUnit 3 style test looks as follows.
-
-**JUnit 3 test with default resource file.**
-
-    public class MyBusinessProcessTest extends FlowableTestCase {
-
-      @Deployment
-      public void testSimpleProcess() {
-        runtimeService.startProcessInstanceByKey("simpleProcess");
-
-        Task task = taskService.createTaskQuery().singleResult();
-        assertEquals("My Task", task.getName());
-
-        taskService.complete(task.getId());
-        assertEquals(0, runtimeService.createProcessInstanceQuery().count());
-      }
-    }
-
-To get the same functionality when using the JUnit 4 style of writing unit tests, the org.flowable.engine.test.FlowableRule Rule must be used. Through this rule, the process engine and services are available through getters.
-As with the FlowableExtension (see above), including this Rule will enable the use of the org.flowable.engine.test.Deployment annotation (see above for an explanation of its use and configuration) and it will look for the default configuration file on the classpath. Process engines are statically cached over multiple unit tests when using the same configuration resource.
-
-The following code snippet shows an example of using the JUnit 4 style of testing and the usage of the FlowableRule.
-
-**JUnit 4 test with default resource file.**
-
-    public class MyBusinessProcessTest {
-
-      @Rule
-      public FlowableRule flowableRule = new FlowableRule();
-
-      @Test
-      @Deployment
-      public void ruleUsageExample() {
-        RuntimeService runtimeService = flowableRule.getRuntimeService();
-        runtimeService.startProcessInstanceByKey("ruleUsage");
-
-        TaskService taskService = flowableRule.getTaskService();
-        Task task = taskService.createTaskQuery().singleResult();
-        assertEquals("My Task", task.getName());
-
-        taskService.complete(task.getId());
-        assertEquals(0, runtimeService.createProcessInstanceQuery().count());
-      }
-    }
-
 ## Debugging unit tests
 
 When using the in-memory H2 database for unit tests, the following instructions allow you to easily inspect the data in the Flowable database during a debugging session. The screenshots here are taken in Eclipse, but the mechanism should be similar for other IDEs.

docs/docusaurus/docs/bpmn/ch05-Spring.md

@@ -218,13 +218,12 @@ In addition to using the values listed above for deploymentMode, you may require
 ## Unit testing
 
 When integrating with Spring, business processes can be tested very easily using the standard [Flowable testing facilities](bpmn/ch04-API.md#unit-testing).
-The following examples show how a business process is tested in typical Spring-based JUnit 4 and 5 test:
+The following examples show how a business process is tested in typical Spring-based JUnit Jupiter test:
 
 **JUnit 5 test.**
 
     @ExtendWith(FlowableSpringExtension.class)
-    @ExtendWith(SpringExtension.class)
-    @ContextConfiguration(classes = SpringJunitJupiterTest.TestConfiguration.class)
+    @SpringJUnitConfig(SpringJunitJupiterTest.TestConfiguration.class)
     public class MyBusinessProcessTest {
 
       @Autowired
@@ -248,41 +247,6 @@ The following examples show how a business process is tested in typical Spring-b
 
 Using the FlowableSpringExtension allows the usage of the Deployment annotation.
 
-**JUnit 4 test.**
-
-    @RunWith(SpringJUnit4ClassRunner.class)
-    @ContextConfiguration("classpath:org/flowable/spring/test/junit4/springTypicalUsageTest-context.xml")
-    public class MyBusinessProcessTest {
-
-      @Autowired
-      private RuntimeService runtimeService;
-
-      @Autowired
-      private TaskService taskService;
-
-      @Autowired
-      @Rule
-      public FlowableRule flowableSpringRule;
-
-      @Test
-      @Deployment
-      public void simpleProcessTest() {
-        runtimeService.startProcessInstanceByKey("simpleProcess");
-        Task task = taskService.createTaskQuery().singleResult();
-        assertEquals("My Task", task.getName());
-
-        taskService.complete(task.getId());
-        assertEquals(0, runtimeService.createProcessInstanceQuery().count());
-
-      }
-    }
-
-Note that for this to work, you need to define an *org.flowable.engine.test.Flowable* bean in the Spring configuration (which is injected by auto-wiring in the example above).
-
-    <bean id="flowableRule" class="org.flowable.engine.test.Flowable">
-      <property name="processEngine" ref="processEngine" />
-    </bean>
-
 ## JPA with Hibernate 4.2.x
 
 When using Hibernate 4.2.x JPA in service task or listener logic in the Flowable engine, an additional dependency to Spring ORM is needed. This is not needed for Hibernate 4.1.x or earlier. The following dependency should be added:

docs/docusaurus/docs/cmmn/ch03-API.md

@@ -386,10 +386,10 @@ Delete all HistoricCaseInstances and their related data that are older than one
 Cases are an integral part of software projects and they should be tested in the same way normal application logic is tested: with unit tests.
 Since Flowable is an embeddable Java engine, writing unit tests for business cases is as simple as writing regular unit tests.
 
-Flowable supports JUnit versions 4 and 5 styles of unit testing.
+Flowable supports JUnit Jupiter styles of unit testing.
 
-In the JUnit 5 style one needs to use the org.flowable.cmmn.engine.test.FlowableCmmnTest annotation or register the org.flowable.cmmn.engine.test.FlowableCmmnExtension manually.
-The FlowableCmmnTest annotation is just a meta annotation and the does the registration of the FlowableCmmnExtension (i.e. it does @ExtendWith(FlowableCmmnExtension.class)).
+In the JUnit Jupiter style one needs to use the org.flowable.cmmn.engine.test.FlowableCmmnTest annotation or register the org.flowable.cmmn.engine.test.FlowableCmmnExtension manually.
+The FlowableCmmnTest annotation is just a meta-annotation and does the registration of the FlowableCmmnExtension (i.e. it does @ExtendWith(FlowableCmmnExtension.class)).
 This will make the CmmnEngine and the services available as parameters into the test and lifecycle methods (@BeforeAll, @BeforeEach, @AfterEach, @AfterAll).
 Before each test the cmmnEngine will be initialized by default with the flowable.cmmn.cfg.xml resource on the classpath.
 In order to specify a different configuration file the org.flowable.cmmn.engine.test.CmmnConfigurationResource annotation needs to be used (see the second example).
@@ -401,9 +401,9 @@ In case there are no resources defined, a resource file of the form testClassNam
 At the end of the test, the deployment will be deleted, including all related case instances, tasks, and so on.
 See the CmmnDeployment class for more information.
 
-Taking all that into account, a JUnit 5 test looks as follows:
+Taking all that into account, a JUnit Jupiter test looks as follows:
 
-**Junit 5 test with the default resource.**
+**Junit Jupiter test with the default resource.**
 
     @FlowableCmmnTest
     class MyTest {
@@ -436,9 +436,9 @@ Taking all that into account, a JUnit 5 test looks as follows:
       }
     }
 
-    With JUnit 5 you can also inject the id of the deployment (with +org.flowable.cmmn.engine.test.CmmnDeploymentId+_) into your test and lifecycle methods.
+With JUnit Jupiter you can also inject the id of the deployment (with +org.flowable.cmmn.engine.test.CmmnDeploymentId+_) into your test and lifecycle methods.
 
-**Junit 5 test with custom resource.**
+**Junit Jupiter test with custom resource.**
 
     @FlowableCmmnTest
     @CmmnConfigurationResource("flowable.custom.cmmn.cfg.xml")
@@ -470,40 +470,3 @@ Taking all that into account, a JUnit 5 test looks as follows:
         assertEquals(0, cmmnRuntimeService.createCaseInstanceQuery().count());
       }
     }
-
-In the JUnit 4 style, the *org.flowable.cmmn.engine.test.FlowableCmmnTestCase* is available as parent class. It uses a configuration file *flowable.cmmn.cfg.xml* by default or uses a standard CmmnEngine using an H2 in-memory database if such file is missing.
-Behind the scenes, a CmmnTestRunner is used to initialise the CMMN engine. Note in the example below how the *@CmmnDeployment* annotation is used to automatically deploy the case definition (it will look for a .cmmn file in the same folder as the test class and expects the file to be named <Test class name>.<test method name>.cmmn.
-
-    public class MyTest extends FlowableCmmnTestCase {
-
-      @Test
-      @CmmnDeployment
-      public void testSingleHumanTask() {
-        CaseInstance caseInstance = cmmnRuntimeService.createCaseInstanceBuilder()
-                        .caseDefinitionKey("myCase")
-                        .start();
-        assertNotNull(caseInstance);
-
-        Task task = cmmnTaskService.createTaskQuery().caseInstanceId(caseInstance.getId()).singleResult();
-        assertEquals("Task 1", task.getName());
-        assertEquals("JohnDoe", task.getAssignee());
-
-        cmmnTaskService.complete(task.getId());
-        assertEquals(0, cmmnRuntimeService.createCaseInstanceQuery().count());
-      }
-    }
-
-Alternatively, the *FlowableCmmnRule* is available and allows to set a custom configuration:
-
-**JUnit 4 test with a Rule.**
-
-    @Rule
-    public FlowableCmmnRule cmmnRule = new FlowableCmmnRule("org/flowable/custom.cfg.xml")
-
-    @Test
-    @CmmnDeployment
-    public void testSomething() {
-        // ...
-        assertThat((String) cmmnRule.getCmmnRuntimeService().getVariable(caseInstance.getId(), "test"), containsString("John"));
-        // ...
-    }

docs/docusaurus/docs/cmmn/ch04-Spring.md

@@ -173,13 +173,12 @@ In addition to using the values listed above for deploymentMode, you may require
 ## Unit testing
 
 When integrating with Spring, business cases can be tested very easily using the standard standard [Flowable testing facilities](cmmn/ch03-API.md#unit-testing).
-The following examples show how a case definition is tested in typical Spring-based JUnit 4 and 5 test:
+The following examples show how a case definition is tested in typical Spring-based JUnit Jupiter test:
 
-**JUnit 5 test.**
+**JUnit Jupiter test.**
 
     @ExtendWith(FlowableCmmnSpringExtension.class)
-    @ExtendWith(SpringExtension.class)
-    @ContextConfiguration(classes = CmmnSpringJunitJupiterTest.TestConfiguration.class)
+    @SpringJUnitConfig(CmmnSpringJunitJupiterTest.TestConfiguration.class)
     class MyBusinessCaseTest {
 
       @Autowired
@@ -200,22 +199,3 @@ The following examples show how a case definition is tested in typical Spring-ba
       }
     }
 
-**JUnit 4 test.**
-
-    public class MyBusinessCaseTest {
-
-      @Rule
-      public FlowableCmmnRule cmmnRule = new FlowableCmmnRule("org/flowable/spring/test/el/SpringBeanTest-context.xml");
-
-      @Test
-      public void simpleCaseTest() {
-        cmmnRule.getCmmnRepositoryService().createDeployment().addClasspathResource("org/flowable/spring/test/el/springExpression.cmmn").deploy();
-        CmmnRuntimeService cmmnRuntimeService = cmmnRule.getCmmnRuntimeService();
-        CaseInstance caseInstance = cmmnRuntimeService.createCaseInstanceBuilder()
-                .caseDefinitionKey("myCase")
-                .variable("var1", "John Doe")
-                .start();
-
-        Assert.assertNotNull(caseInstance);
-      }
-    }

docs/docusaurus/docs/dmn/ch03-API.md

@@ -86,16 +86,16 @@ Sometimes you need more powerful queries, for example, queries using an OR opera
 
 As Flowable DMN is an embeddable Java engine, writing unit tests for DMN definitions is as simple as writing regular unit tests.
 
-Flowable supports the JUnit version 4 and 5 style of unit testing.
+Flowable supports the JUnit Jupiter style of unit testing.
 
-In the JUnit 5 style one needs to use the org.flowable.dmn.engine.test.FlowableDmnTest annotation
+In the JUnit Jupiter style one needs to use the org.flowable.dmn.engine.test.FlowableDmnTest annotation
 or register the org.flowable.dmn.engine.test.FlowableDmnExtension manually.
-The FlowableDmnTest annotation is just a meta annotation and the does the registration of the FlowableDmnExtension
+The FlowableDmnTest annotation is just a meta-annotation and does the registration of the FlowableDmnExtension
 (i.e. it does @ExtendWith(FlowableDmnExtension.class)).
 This will make the DmnEngine and the services available as parameters into the test and lifecycle methods
 (@BeforeAll, @BeforeEach, @AfterEach, @AfterAll).
 Before each test the dmnEngine will be initialized by default with the flowable.dmn.cfg.xml resource on the classpath.
-In order to specify a different configuration file the org.flowable.dmn.engine.test.DmnConfigurationResource
+To specify a different configuration file the org.flowable.dmn.engine.test.DmnConfigurationResource
 annotation needs to be used (see second example).
 Dmn engines are cached statically over multiple unit tests when the configuration resource is the same.
 
@@ -110,9 +110,9 @@ in the same package as the test class, will be deployed.
 At the end of the test, the deployment will be deleted, including all related dmn definitions, executions, and so on.
 See the DmnDeployment class for more information.
 
-Taking all that in account, a JUnit 5 test looks as follows:
+Taking all that into account, a JUnit Jupiter test looks as follows:
 
-**JUnit 5 test with default resource.**
+**JUnit Jupiter test with default resource.**
 
     @FlowableDmnTest
     class MyDecisionTableTest {
@@ -132,9 +132,9 @@ Taking all that in account, a JUnit 5 test looks as follows:
       }
     }
 
-    With JUnit 5 you can also inject the id of the deployment (with +org.flowable.dmn.engine.test.DmnDeploymentId+_) into your test and lifecycle methods.
+With JUnit Jupiter you can also inject the id of the deployment (with +org.flowable.dmn.engine.test.DmnDeploymentId+_) into your test and lifecycle methods.
 
-**JUnit 5 test with custom resource.**
+**JUnit Jupiter test with custom resource.**
 
     @FlowableDmnTest
     @DmnConfigurationResource("flowable.custom.dmn.cfg.xml")
@@ -155,34 +155,6 @@ Taking all that in account, a JUnit 5 test looks as follows:
       }
     }
 
-When writing JUnit 4 unit tests, the org.flowable.dmn.engine.test.FlowableDmnRule Rule can be used. Through this rule, the DMN engine and services are available through getters. Including this Rule will enable the use of the org.flowable.dmn.engine.test.DmnDeploymentAnnotation annotation (see above for an explanation of its use and configuration) and it will look for the default configuration file on the classpath. DMN engines are statically cached over multiple unit tests when using the same configuration resource.
-It’s also possible to provide a custom engine configuration to the rule.
-
-The following code snippet shows an example of using the JUnit 4 style of testing and the usage of the FlowableDmnRule (and passing an optional custom configuration):
-
-**JUnit 4 test.**
-
-    public class MyDecisionTableTest {
-
-      @Rule
-      public FlowableDmnRule flowableDmnRule = new FlowableDmnRule("custom1.flowable.dmn.cfg.xml");
-
-      @Test
-      @DmnDeploymentAnnotation
-      public void ruleUsageExample() {
-        DmnEngine dmnEngine = flowableDmnRule.getDmnEngine();
-        DmnRuleService dmnRuleService = dmnEngine.getDmnRuleService();
-
-        Map<String, Object> executionResult = ruleService.createExecuteDecisionBuilder()
-                .decisionKey("extensionUsage")
-                .variable("inputVariable1", 2)
-                .variable("inputVariable2", "test2")
-                .executeWithSingleResult();
-
-        Assertions.assertThat(executionResult).containsEntry("output1", "test1");
-      }
-    }
-
 ## The DMN engine in a web application
 
 The DmnEngine is a thread-safe class and can easily be shared among multiple threads. In a web application, this means it is possible to create the DMN engine once when the container boots and shut down the engine when the container goes down.