JUnit seems to have come under fire recently, with articles such as this, and posts like this one from Geoff and this one from Cedric. The Artima article complains that JUnit’s reporting features are underdeveloped, and Cedrid & Geoff want to see success messages as well as failure ones.

JUnit is a ‘unit testing’ tool. Its supposed to be run many times a day. Its output is supposed to be transient. All the tests are supposed to pass all the time. Red bar / green bar. Pass or fail. If all the tests are passing it should remain silent. If a test fails, print a useful message. If you have a suite of thousands of tests, how easy is it to find 1 failure message if its mired inside 999 inane ‘test passed, foo does equal foo’ printouts?

The same goes for reporting. It is actually possible to get detailed reports from JUnit as XML, which can be processed by an ANT task to produce nice looking web pages, but if its being used correctly, all the tests would always be at 100%, as you don’t commit if any of the tests are failing, right?

Bolting on extra features blurs the line between functional testing and unit testing, and I for one am happy for JUnit to remain clearly focussed on doing one job very well, which it does admirably.

Side note: The Artima article is called ‘Why we refactored JUnit’. Following neatly on from my earlier post, what they did was neither big-R or little-R. What they actually did was write a brand new, JUnit testcase compatible tool from the ground up. Refactoring is defined as ‘improving the design of existing code’. In the strictest sense the only people who can refactor JUnit are the JUnit committers and contributers, and the result would still have been JUnit, with all the same behaviour, but with a cleaner internal structure.

Something Alan said a few weeks ago has just bubbled to the surface: there appear to be two main ways that people think about refactoring. I’m going to call them ‘Refactoring’ (big ‘R’) and ‘refactoring’ (small ‘r’).

The apparently more common usage is the big-R form, Refactoring as a task in its own right. Typical comments would be “We have to spend the next two weeks Refactoring this system”. The small-r form is done as part of everyday programming activities, at the same level as writing statements and method calls. Nobody says, “Today my tasks will include writing for-loops, methods and if-else statements.” (Although that is a great way of describing your activities without actually saying anything about what you will be doing.)

The XP / Test-first crowd tend to think of refactoring in the small-r sense. Its just one piece of the Test-Code-(r)efactor cycle that they go through many times a day. In this way (in a perfect world), the code is kept clean and lean enough that Refactoring (big-R) is never required. Having to plan a Refactoring session for some code probably means that its in what the XP books call ‘Refactoring debt’ (its like oxygen debt for software). The system wasn’t refactored mercilessly enough (if at all) while it was being grown, and, just like a human in oxygen debt, progress slows down and pain increases, until it becomes necessary to stop and do something about it, in a big Refactoring session.

I am of the opinion that just as aerobic exercise (eg. jogging) is less painful and can be done for longer than anaerobic exercise (eg. sprinting), its better to keep to the discipline of refactoring as you go (ideally as part of the test-code-refactor cycle), and try to minimise the incidences of Refactoring required (during which customer-visible progress tends to slow or stop).

Eclipse has a Perl plugin! The power and flexibility of Perl, coupled with the productivity benefits of code completion and syntax highlighting. Nice.

Reading ‘The Mythical Man Month’ currently. Cool fact I learned today: in 1969 or thereabouts, it cost $12 a month to rent a Kb of RAM. So I could charge out the machine I’m typing this on for approximately $10,000,000 a month, at 1969 prices. Taking inflation into account, its probably more like half a billion dollars. Every month.

Any takers?

http://www.cafeconleche.org/XOM/

Realised the other day that javablogs has become my news aggregator. This means that I’ve lost track of those blogs not on it, Russ’s being one. Too much pure java probably isn’t good for you.

So here’s something completely different:

Earth
Air
Water
Fire

If that all seems too energetic, there’s always Drink.

If you absolutely must be coding, try these:

http://www.perl.com/
http://www.python.org/
http://www.erlang.org/
http://www.scheme.org/
http://www.haskell.org/

And of course…
Intercal: home of the coolest programming construct ever. Who needs GOTO when you have… COME FROM!

For those times when java is just too damn boring.