Home > technical > TDD Overhype

TDD Overhype

There is much to like about unit-level testing and its extreme cousin, Test Driven Design (TDD). However, like with any tool/technique/methodology, beware of overhyping by snake oil salesman.

Cédric Beust is the author of the book, “Next Generation Java Testing“. He is also the founder and lead developer of TestNG, the most widely used Java testing framework outside of JUnit. In a Dr. Dobb’s guest post titled “Breaking Away From The Unit Test Group Think”, I found it refreshing that a renowned unit testing expert, Mr. Beust, wrote about the down side of the current obsession with unit testing:

  • Unit tests are a luxury. Sometimes, you can afford a luxury; and sometimes, you should just wait for a better time and focus on something more essential — such as writing a functional test.
  • There are two specific excesses regarding code coverage: focusing on an arbitrary percentage and adding useless tests.
  • TDD code also tends to focus on the very small picture: relentlessly testing individual methods instead of thinking in terms of classes and how they interact with each other. This goal is further crippled by another precept called YAGNI, (You Aren’t Going to Need It), which suggests not preparing code for features that you don’t immediately need.
  • Obsessing over numbers in the absence of context leads developers to write tests for trivial pieces of their code in order to increase this percentage with very little benefit to the end user (for example, testing getters).

Being a designer and developer of real-time, multi-threaded code that runs 24 X 7, I’ve found that unit testing is not nearly as cost effective as functional testing. As soon as I can, I get a skeletal instance of the (non-client-server) system that I’m writing up and running and I pump deterministic, canned data streams through the system from end-to-end to find out how the beast is behaving.  As I add functionality to the code base, I rerun the data streams through the system again and again and I:

  • try to verify that the new functionality inserted into the threading structure works as expected
  • try to ensure that threads don’t die,
  • try to verify that there are no deadlocks or data races in the quagmire

If someone can show me how unit testing helps with these issues, I’m all ears. No blow hard pontificating, please.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: