Create complementary unit tests for integrations tests

[andchiind]

Describe the improvement you would like to see
Currently we are highly dependent on larger integration tests where there are several threads interacting with each other. These are good for testing that the system as a whole is healthy, but they are not useful for identifying what the causes for issues are. I would therefore like us to have complementary tests for each integration test (the tests that include more than one thread, or which in general includes Thread.sleep), where we instead of having more than one thread we instead specify the specific state that one thread should create, and then simply start the main thread in the given state. So instead of running one thread to create the conditions we wish to test in the second thread, we simply set those conditions manually and then start the thread we wish to test. Ideally we would like to start the specific function in the second thread we wish to test, but this is a good start. By controlling the state more precisely we are also more precise in understanding issues in the code.

How will this change existing functionality?
We will be able to not only identify that there is an issue, but also what the issue is. Currently a lot of effort is used in debugging tests, which indicates that we are lacking in tests. A unit test should be simple enough that finding a cause should be more or less trivial.

How will this improvement affect the current Threat Model?
It will improve maintainability of the code, reducing vulnerabilities.

[Christdej]

Skipping test:
QueuedContinuesWhenOnIsarStatusHappensAtTheSameTimeAsOnIsarMissionCompleted
Until this is solved

[aeshub]

This issue has automatically been marked as stale as there has been no activity for 60 days.