We have a master flow that manages a number of sub flows. The subflows are seperate bpmn flows that are called through CallActivity.
The sub flow has interactions with other systems, and updates a database record with the results.
We need a number of scenario tests (maven integration tests) for the master flow, during which the subflows are called. To make the tests more managable, we replace the actual flow with a test flow that has a task where we can insert the end results we want from the flow.For this test flow we can register callables that will be called when the flow executes (we store the callables in a list in the bean and use them one after each other when the activity java code is called).
In activiti this worked fine.
In flowable it works if you only run this test (reliably, done it a huge number of times)
However, if we run the full test suite the test fails.
What we found after quite some searching and adding logs etc.is that the registered callables were not called, resulting in the test failing. In stead the default behavior encoded was called (a strong point against default behavior for test classes). We could not find any coding error, so we added logging statements to all bean operations that show the operation name and the hashcode of the bean.
This showed the following:
- The flowable process uses the bean that is created when we start the tests (so it uses the initial application context or it somehow caches the bean internally).
- The test uses the bean that is created most recently. In tests beans get recreated as the application for all tests is not the same. (We also log this info from the constructor)
As the test and flow use different beans, the configuration done by the test is not picked up by the flow.
We have tried to a number of work arounds to enforce singleton behaviour:
-
Tried to enforce only one application context for all tests, but we were not able enforce this.
-
Moved from a scanned bean to using a TestConfiguration with a bean factory method that always returned the same instance. The bean could then not be found by the flow, but it was wired into the test, not even when we qualified it with the correct names.
Question: Is there a reason beans are picked up from test code using scanning, but not from TestConfigurations (the test configuration is imported in the application context with @Import -
We made the state static within the bean, so all beans share the state. This works, at least in this case.
We are using the SpringBeanFactoryProxyMap:
configuration.setBeans(new SpringBeanFactoryMap(configuration.getApplicationContext());
However, we really would like to know why the flowable process doesn’t pick up the bean from the latest application context during testing, as we suspect that further on in the migration process we might run into similar issues that might not be easily fixable