Unit test RiskLevelCalculatorTester.testCurrentOrFutureRiskCalculation was disabled some time ago when it was found that the test failed, but the same sequence run manually did not. It was assumed that the test framework introduced some dependency between the two risk calculation steps (one current risk, one future risk), but the cause could not be found.

Subsquently it seemed more likely that the problem was caused by the use of 'artificial' controls added to the domain model to regulate some threats that should not be included in a current risk calculation. The test framework did not know that these should be enabled or disabled before re-running the risk calculation. This may have been the cause of the original problem. See Spyderisk/domain-network#28.

Meanwhile, some risk calculation steps have been moved to the Jena querier class so they can be used in the validator to initialise control sets and trustworthiness attribute sets when first generated. To support this, some risk calculation initialisation has also been moved into the querier, which may cause problems if a risk calculation is re-run in the same thread using the same querier. This could not be a cause of the original unit test failure, but may mean the unit test will still fail if used with an up-to-date domain model in which artificial control strategies have been removed.

This issue has become more important now we are seeking to integrate a control strategy recommendation algorithm into the system-modeller code. This will be using a risk calculator inside an iterative search procedure, leading to repeated risk calculation runs in a single thread. We should now find out whether the unit test works if fed an up-to-date test case with no artificial controls, and if not, determine whether the cause may affect the envisaged control strategy recommendation algorithm.