Rx for unit testing: Use with moderation
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Andrew Binstock
June 15, 2008 —
Of all the good things the agile revolution has brought to software development, the most important is unit testing. Developers who become test-enamored generally report immediate benefits:
1) Code is better written. When made as testable as possible, code generally becomes more reliable and easier to read.
2) Less time is spent debugging, as code can be tested as it’s written. So, there are no nasty surprises later. Rather, large sets of changes can be made with confidence that they will work, not with a sense of trepidation.
3) Managers have a truer sense of a project’s development timeline. In the old days, if the schedule called for six weeks of coding and three weeks of testing and debugging, you had no way of knowing how much more testing and recoding were in store after coding had been completed.
However, unit testing gives you confidence that there will be few surprises after the initial coding period. Sure, there will probably be some modifications, but not the type of vast rewriting that reverberates through many other modules and functions. In sum, you get better code and a diminished need to debug. Ultimately, you have a good sense of where you are in relation to timelines and project delivery from a practice that does not cost much in time.
You would think that a technique that delivers so much and that has excellent free tools to support it would be widely embraced. And, in fact, that’s what I thought—until a few weeks ago. But several data points now raise concerns. The first came from Ivan Moore, the author of Jester, a tool I covered in my column titled “Integrate, then mutilate, your code.”
Jester examines your code and, through various tricks, tries to determine if you’ve overlooked a test that could be important. When I met Moore at the CitCon conference last year, he told me he had discontinued work on Jester because the number of sites that really cared about the qualitative extent of their unit tests was so small that there was virtually no point refining the product for their use.
Then came the news that tool vendor Agitar, whose entire fate hinged on the adoption of unit testing, was closing down. The company had excellent products for unit testing and even offered a free service that would generate unit tests for your code. Despite great tools, free services and a dynamic advocate in founder Alberto Savoia, Agitar folded because, according to CEO Jerry Rudisin, “The market we served was just not big enough.”
So neither a single paying business with no direct competition, nor a freeware tool, could attract enough support to keep going. That’s disappointing. But other factors were also at work: Established Java developers were discouraging or complaining about unit tests. For example, Cay Horstmann, a professor at San Jose State University and a co-author of the excellent two-volume Java tutorial “Core Java,” said recently that he does not unit-test much. Because many others don’t either, he observed, “If so many experienced developers don’t write unit tests, what does that say?” In my view, you should answer this question by matching the defect rate of those developers’ code with that of code written by developers who do use unit testing.
Part of the problem might be the perception that writing unit tests steals time from coding. Consider, for example, this comment from Howard Lewis Ship, the highly regarded founder of the Tapestry Web framework: “I'm losing some faith in unit testing, or at least busywork unit testing relative to integration testing.” He goes on to state that he still believes in unit testing, but he would like to limit what he writes tests for.
There is no doubt that unit testing can be overdone. Some mistaken aficionados feel it’s imperative to test 100% of code. (No major proponent of unit testing agrees with that view.) And the test-driven development folks also may contribute to the confusion about what to test by insisting that everything be tested even before code is written.
Naturally, there needs to be sensible moderation. But it’s crucial to understand that time spent writing tests does not generally extend a project; rather, that time is recouped from the testing and debugging phases. Managers and developers who understand that will be richly rewarded.
Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.
Related Search Term(s): Java, testing & troubleshooting
Share this link: http://sdtimes.com/link/32252