leastfixedpointUnit testing in Java vs. Smalltalk
Fri, 22 February 2008
When you write unit tests, the minimal requirement before being able to try them out is that they compile. In Smalltalk, this means things like syntactic well-formedness, and perhaps the presence of global variables (i.e. classes) that you reference in the test method body.
It’s very quick and comfortable in Smalltalk to develop supported by unit testing: to write tests you know will fail, and refine away the failures until your test suite passes.
In Java, it’s much less comfortable, because besides the basic requirement of syntactic well-formedness, all the methods, classes, interfaces, and packages that your code relies on, directly or indirectly, must be present in the system before you can even try a run of the test suite! This makes for a less incremental style of development.
It would be very interesting to see a unit-testing framework for Java that simply treated a non-compiling test as a normal test failure, rather than a complete show-stopper, and which let you continue with the other tests in the suite. At the end of a run, it would include the non-compiling tests in the final reports just the same way as any other unexpectedly-failing test is reported.
Comments
On 22 February, 2008 at 5:13 pm, wrote:
On 26 February, 2008 at 9:44 am, wrote:
I think you may want JMockObjects. Also, if you always write to interfaces rather than classes then this makes life easier too.
Of course, really the type system should just carry around proofs and logical discriptions of what individual functions actually do and should know how these compose together.
On 26 February, 2008 at 10:45 am, wrote:
Matthew, I can see how interfaces remove some of the burden, but how would mock objects help? Also, all this hassle just to stop the compiler from simple-mindedly complaining about something I know I haven’t gotten around to yet… even using interfaces doesn’t fix the ergonomics of the system.
On 26 February, 2008 at 10:46 am, wrote:
Neil, it sounds like Eclipse is moving in the right direction. It’s a pity that lighter tools don’t work the same way.
Give the Eclipse project another couple of years, and we’ll have a lovely greenspunned Strongtalk-a-like :-)
Eclipse “compiles away” compile errors as runtime exceptions so running the tests inside Eclipse essentially gives you this for free.