If no configuration is provided before the first assertion is run, an NPE occurs when trying to load a ResourceBundle for the messages. This is because ProcessAssert.getConfiguration() returns null.
This should be changed so that ProcessAssert.getConfiguration() never returns null, by lazy loading a default configuration if none was set. Such a DefaultProcessAssertConfiguration will already attempt to reference the EngineServices from the default process engine registered to the ProcessEngines class, so for most cases this automatic fallback should work out of the box.
Additional benefit of this approach is that there is no need to provide a configuration, if the EngineServices can be determined correctly. This means a significant improvement and a simple test case has proven that this also works as expected for test cases setup using an ActivitiRule. Therefore, this prevents having the configuration reset over and over in @Before methods simply because the ActivitiRule is not available in static code such as @BeforeClass.
For those test cases where the user decides to initialize the ProcessEngine themselves, the current configuration options still make perfect sense.
If no configuration is provided before the first assertion is run, an NPE occurs when trying to load a ResourceBundle for the messages. This is because ProcessAssert.getConfiguration() returns null.
This should be changed so that ProcessAssert.getConfiguration() never returns null, by lazy loading a default configuration if none was set. Such a DefaultProcessAssertConfiguration will already attempt to reference the EngineServices from the default process engine registered to the ProcessEngines class, so for most cases this automatic fallback should work out of the box.
Additional benefit of this approach is that there is no need to provide a configuration, if the EngineServices can be determined correctly. This means a significant improvement and a simple test case has proven that this also works as expected for test cases setup using an ActivitiRule. Therefore, this prevents having the configuration reset over and over in @Before methods simply because the ActivitiRule is not available in static code such as @BeforeClass.
For those test cases where the user decides to initialize the ProcessEngine themselves, the current configuration options still make perfect sense.