During the last few days, I continued to struggle with my Concutest-JUnit extensions. The JUnit code inside is an absolute mess; I’m probably stepping on someone’s toes right now, but the code is ugly, overly complex and unnecessarily convoluted, and it’s barely commented (except for important details like “Parts of this method were written at 2337 meters in the Hueffihuette, Kanton Uri”).
I added a @Test annotation parameter to disable the requirement to join with all spawned threads: @Test(forceThreadJoin=false) public void foo() { ... }. In JUnit3-style tests, you can now append the suffix "\_NOJOIN" to a method name to disable forced joins. With JUnit 3, the test above therefore has to be written as public void testFoo\_NOJOIN() { ... }.
I also extended my set of unit tests for the unit testing suite (that’s a rather weird concept, to unit test the unit testing library using the unit testing library being tested; I’m not sure that’s really sound). JUnit4 already includes parameters for timeouts, so I’m not sure if I’m going to add that to my library; it would also have to go into the method name, and that might really get hard to read: public void testFoo\_TIMEOUT30s\_NOJOIN() { ... }.
When I dropped my new Concutest-JUnit jar file into DrJava, I got a bunch of weird RMI exceptions, though. I expected some problems, but not that many. Of course, first I thought I must have done something wrong, and I could understand if changing the threading behavior of unit tests has some influence on RMI. I changed the tests that failed to use the "_NOJOIN" suffix and rewrote my JUnit extensions to use the original JUnit4 code in that case. But I was still getting the exceptions…
So I plugged in the unmodified JUnit4 library, ran the tests, and I was still getting the errors. So the problem was not related to my changes. When I looked closer, I found out that junit.runner.TestCaseClassLoader [1] was deleted when JUnit went from version 3.8.2 to 4.0, and this is a class that DrJava depends on. So despite all claims, JUnit4 is not backward-compatible with previous versions.
I’m sure there is a way to make DrJava work just like before without TestCaseClassLoader, but I’m not familiar with the affected code, neither in DrJava nor in JUnit. Furthermore, Dan reminded me today that we can’t actually bundle JUnit4 with DrJava yet, because JUnit4 requires at least Java 5.0, and we are still supporting Java 1.4. That means for now I’ll also create a modified version of JUnit 3.8.2.
It’s freezing today (literally; I’m wearing three pairs pants concurrently, so far without any deadlocks), it’s almost 6 PM and already dark, so I’m going to bike home now. I’m going to create Concutest-JUnit3.8.2 when I’m at home, perhaps after dinner, or even after dinner and a nap. But that’s ok, I’ve done quite a bit today: Besides my JUnit work, I’ve made four DrJava commits, mainly bugfixes, but also a new “Copy System Properties” button in the “About” dialog to make it easier for users to supply us with important system information.
TTFN.
Update
When I got back from work, I found the SATA cable in my mailbox. Unfortunately, it angled in just the opposite direction. I was still able to route the cable and close the side panel of my new machine, though.
