JUnit: A critical look
By Angsuman Chakraborty, Gaea News NetworkTuesday, August 10, 2004
As a model of XP development (done at a few thousand feet above ground) I was expecting a solid bug free transperant code for JUnit.
I noticed few interesting bugs & surprising features in the code.
If you want to increase your test count (possibly for your manager who checks the tests written or for your customer) by a factor x (without actually performing the tests) then just override the default implementation of countTestCases() to return x. The documentation says “Counts the number of test cases executed by run(TestResult result)”. However in reality it always returns 1.
If you have 10 test cases in your Test class and if you return 20 in your impl. of countTestCases() then the total test count is shown as 200. However in reality only 10 tests are run.
The code has interesting tests performed on a TestCase subclass like it checks that there is at least one method with name starting with test (could be just test() ). It checks that there is a public constructor which accepts a string as parameter. It could still do nothing.
These are interesting ideas half-baked which feels forced on the user, specially when you decide to override the default implementation to hook it to your test generator. Also you might have noticed that the error messages are often not very illuminating when the cons is missing.
The code does this funny passing back and forth with run variants between TestCase & TestResults for no apparent reason before finally calling testBare. Methods like runProtected or run variants belong to TestCase. At the least lets keep the run methods in one class instead of calling each other back and forth.
|
August 11, 2004: 4:57 am
“their user stories didn’t foresee it” — that’s it. Kent Beck’s JUnit was written to certain (probably not documented) specifications and assumptions. It actually works well for its intended purposes, though there is a Smalltalk flavor to it that someone who came to Java from other languages would not appreciate. I expect that TestSuite() overrides countTestCases() appropriately… but the framework is not written to prevent people from abusing it, since that would get in the way of people who need to extend it for legitimate reasons. I suspect that “TestResults” is following the Smalltalk idiom of a “collecting parameter” (see Kent Beck’s book “Smalltalk Best Practice Patterns”. |
 x |
|
August 10, 2004: 11:28 am
The design assumes you implement Test, and that’s all. However, it provides _convenience_ methods (such as TestCase) that allow you to write Tests with a minimum of fuss. Yes, it’s not overly defensive: it makes the assumption that the developer is trying to use it, not abuse it. If you look at the lifecycle of the tests, BTW, you’ll see why the run method is passed back and forth. |
|
x |
keith ray