The Disco Blog

Ever since Agitar lamentably shut its doors earlier this summer, there have been quite a few postings stating, predicting, or refuting the demise of unit testing. In fact, I was lucky enough to be quoted in one hip article regarding this subject written by my good friend Andrew Binstock. In his article, dubbed “Is unit testing dooomed?” Andrew does not, in fact, reach the conclusion that the practice of unit testing is doomed– he merely suggests that there might be sufficient evidence to conclude the practice might have not caught on like most of us think has.

He states that while other languages (Python and Ruby are named) appear to have a strong following of unit testing,

there are signs that, in the Java community at least, resistance has built up against the unit testing idea.

Andrew goes on to note that, in many cases “unit testing seems to offer little value” and that “evangelism [such as TDD] has become so overbearing that it makes unit testing as a whole unappealing.” Because it’s his bag, he then goes on to make a compelling case for unit testing naming four benefits, which, for those of us that actually practice unit testing, are hard to refute:

Defects are identified nearly immediately, and because unit testing isolates their cause and effect, they are also resolved more quickly. As a result, you can be more confident in the schedule. You also get better code-level documentation.

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

Unit testing is thriving in that crowd– people often claim (me included) that they can’t live without it! In fact, to the multitude that lives and breathes unit testing, the subject has most likely become simply boring. JUnit, by this point, is old hat– it was super interesting almost a decade ago and when 4.0 came out it was something to chat about, but for the most part, there isn’t much more to say about unit testing in general (for evidence of this, read InfoQ.com’s posting and the subsequent comments dubbed “JUnit Still Not Dead“). Sure, few books regarding JUnit have been published lately and Google’s trends seem to indicate that no one searches on JUnit. But guess what? I don’t need anymore copasetic books on JUnit– I’ve read them and I’ve got enough knowledge now on how to properly utilize it. I have zero need to go to JUnit’s website either– there’s nothing new there. In fact, in some cases, people have moved on to other frameworks, like TestNG (at least one person, other than me, is also using easyb!).

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

In fact, Andrew correctly quoted me as stating in response to why I don’t implement a lot of TestNG solutions for companies:

most organizations do so little unit testing, if any, that I stick with the simple, well-known xUnit tools, so as not to create confusion. Most organizations are just not ready to learn anything more than basic unit testing — if that.

Many of these companies are the entire reason why there is a Java based financial ecosystem. They are why products like Websphere exist. They are why products like JBuilder existed. They are also the same companies that companies like Agitar hoped would buy their products.

These companies employ a lot of trippin’ developers. These companies have many projects that are huge. Unit testing for these companies is like trying to eat an elephant– you can start with one bite, but the overall task is daunting! When people, who work on these projects, hear evangelists bang the TDD drum, many are left scratching their heads– “how do I write a unit test for an application that has more dependencies on external systems than I have figures on both my hands? It would take me longer to handle the dependencies than to just code the feature.” (True, there is folly in this statement, however, this statement is uttered daily across the globe, man.)

These comments and this line of thinking by people faced with maintaining these code bases on a daily basis then logically answers the question of why would someone assert that unit testing “seems to offer little value” and evangelism “has become so overbearing that it makes unit testing as a whole unappealing”– for these folks, the strict term unit testing is doomed.

Don’t get me wrong, it isn’t that unit testing is impossible for these code bases and these teams. I’ve made a career of assisting in this arena; however, this is no easy task. It takes years to effectively introduce cultural change that can yield disciplined unit testing across an organization. In fact, in these situations, you can’t introduce unit testing alone– to effectively gain the manifold benefits of proper unit testing, you need an entire infrastructure to support it– namely, you need continuous integration, which means you need predictable builds.

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?

Trackback this Post | Feed on comments to this Post