JUnit: A critical look
By Angsuman Chakraborty, Gaea News NetworkTuesday, August 10, 2004
The design presumes that all test cases should extend TestCase or its subclass. I disagree. I often want to include my test code within the actual class itself. Then I would just want to implement Test to hint the TestRunner or Test Collectors of Ant task that it is a Test begging to be run.
You can get away with just implementing Test. However it requires that you kludge the code with dummy constructors etc., implement run method & countTestCases. When I am implementing run method, I shouldn’t have any restriction on how I name my test methods. However in reality even if your run method runs 10 tests by calling methods like thisIsATest(), the framework still requires that you have one method name starting with test.
Talk about dumb tests!
There are few more, which I am excluding for brevity.
Maybe some of my woes are because I went deep into the guts of the system and their user stories didn’t foresee it (YAGNI 
).
However I still think there are some design flaws in the system that it can do without.
With static import now available, I would at least want to see it gets away with forcing users to extend TestCase.
|
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