Agile TDD — unit or acceptance tests?


I went to a panel discussion on Implementing Agile Methods last night at Seattle SPIN that included as panelists:

·         Rod Claar, a Certified ScrumMaster Practitioner (CSM-P)

·         Steve Tockey is the Principal Consultant at Construx Software

·         Shane Currier a software professional who has led two development teams through the transition to agile software development.

 

Steve brought up a house construction analogy, that in one form or another all the panel’s members picked up on and discussed.  Steve, in building his house had only a 2.5% cost overrun with 2 change orders.   The industry typically sees 30-50% cost over runs (or in Bill Gate’s house a $40M over run on $14M budget).   Steve contended throughout, that often times for known steady requirements you can save money by correctly surfacing them up front, rather than discovering them over time and doing rework.  Steve agrees that for research or exploratory projects with unknown, unsteady requirements, agile is probably better.

 

I wonder if Steve’s conviction in requirements is because he excels at them (his custom house for example), while others struggle (typical over runs).  It is like Michael Jordan saying you just need to jump and shoot better to play basketball like him.

 

 

I found Shane’s input fascinating from the real world experience he had with applying agile to legacy systems.  Rod pointed me to Michael Feathers‘s book and article Working Effectively with Legacy Code and a great quote:

    "The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests."

It is legacy because you can’t be agile with it.  You don’t know if things break when you change it.  The tests are not unit tests, but rather "cover some small area of a system just well enough to provide some ”invariant”".    Further "In a design driven from the beginning using tests, the tests … seed the design, they record the intentions of the designers"

 

Another audience member, in discussions after the panel, made a distinction between two different definitions of TDD that he uses (searching the web, there appears to be no agreement on their meaning or distinction):

    Test Driven Design :  designing based on acceptance tests

    Test Driven Development : coding based on unit tests.

Interestingly, the audience member claims in developing 2M LOC that they didn’t need unit tests, but only acceptance tests and thus had virtually no test maintenance to code refactoring (the design continued to meet the acceptance tests).

 

I’m not going to settle the debate here either.  But already we see 3 types of tests:  Unit tests, Invariant tests, and Acceptance tests.  If I knew exactly which ones you needed when, I’d be rich!
 

Advertisements

About testmuse

Software Test Architect in distributed computing.
This entry was posted in software testing. Bookmark the permalink.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s