I fixed the concurrency problems with Concutest-JUnit. The issues were pretty intricate. I changed the synchronization from a join scheme to a wait/notify scheme. The trickiest bit was getting InterruptedException for timeouts to work correctly: When the test was interrupted because of a timeout, the actual testing thread had to be interrupted as well.
Now I’m testing it with DrJava again. Unfortunately I still have to use the 3.8.2 version, since the 4.0 version isn’t entirely backward compatible, and with the 4.0 version there are a lot of needless RMI exceptions. I’m glad I added the “\_NOJOIN” extension.
The tests that fail so far are:
- InteractionsModelTest
- testInterpretCurrentInteractionWithIncompleteInput
- InteractionsPaneTest
- testPromptListClearedOnReset
- IntegratedMasterSlaveTest
- testItAll
- testImmediateQuiet
- ReaderWriterLockTest
- testMultipleReaders
- testMultipleWriters
- testMultipleReadersAndWriters
In the first two cases, the Concutest-JUnit error was “Thread Wait for Interactions to Exit Thread(edu.rice.cs.util.newjvm.AbstractMasterJVM$1) is still alive“. Since I couldn’t figure out how to change the behavior of DrJava quickly, I just added the “\_NOJOIN” extension.
For the next group of tests in IntegratedMasterSlaveTest, the error was “Thread Wait for SlaveJVM Exit Thread (edu.rice.cs.util.newjvm.AbstractMasterJVM$1) is still alive. Again, since I didn’t want to mess around too much with DrJava, I added “\_NOJOIN”.
For ReaderWriterLockTest I insert join() calls. The tests spawned threads, which would eventually end, but it wasn’t guaranteed that this would happen before the test ended. So I added really inconsequential join() calls.
So far, it looks like the DrJava unit tests are written pretty well. There aren’t very many flaws. One thing I plan to do, though, is to tear out the MultiThreadedTestCase that all concurrent threads ought to extend, and see what happens then, because I think that will be more like a typical testing situation.
