I have now changed the versions 4.1 and 4.2 of Concutest-JUnit so that, in the case of a timeout, @After methods are executed before the check for spawned auxiliary threads is done. This now allows the JUnit’s own TimeoutTest to run smoothly.
This test is a testament to the confused state that unit testing of concurrent programs currently is in. The original TimeoutTest starts a test that enters an infinite loop and therefore violates the timeout constraint set. The test fails, TimeoutTest registers the failure, and therefore declares itself to have been passed successfully. This is good, because it demonstrates that time limits for tests work. But in the background, the test with the infinite loop continues to run… and run… and run… and it never finishes. It in fact prevents the Java VM from terminating. And that’s considered a success? It’s ironic that TimeoutTest itself is an example of a badly written concurrent unit test, one that spawns a thread and declares success before the spawned thread has ended.
I have now modified the test to include an @After method that sets a flag and therefore causes the (not-so-infinite-anymore) loop to exit. Without this, my Concutest-JUnit would have declared the test a failure because it concluded before all its spawned threads had died.
