Take the 2-minute tour ×

The TDD cycle is test, code, refactor, (repeat) and then ship. TDD implies development that is driven by testing, specifically that means understanding requirements and then writing tests first before developing or writing code.

My natural inclination is a philosophical bias in favor of TDD; I would like to be convinced that there are other approaches that now work well or even better than TDD so I have asked this question. There are other questions that suggest TDD is expensive, tough to implement, presents challenges ... agreed, but what are good alternatives?

What are good examples of perfectly acceptable approaches that do not use/need/require test driven development?

I can think of plenty approaches that are not TDD but could be a lot more trouble than what they are worth ... it's not moral judgement, it's just that they are cost more than they are worth ... the following are simply examples of things that might be ok as learning exercises, but approaches I'd find to be NOT acceptable in serious production and NOT TDD might include:

  • Inspecting quality into your product -- Focusing efforts on developing a proficiency in testing/QA can be problematic, especially if you don't work on the requirements and development side first ... symptom of this include bug triaging where the developers have so many different bugs to deal with it, it is necessary to employ a form of triage -- each development cycle gets worse and worse, programmers work more and more hours, sleep less and less, struggle to keep going in death march until they are consumed.
  • Superstition ... believing in things that you don't understand -- this would involve borrowing code that you believe has been proven or tested from somewhere, e.g. legacy code, a magic code starter wizard or an open source project, and you go forward hacking up a storm of modifications, sliding FaceBook Connect into your the user interface, inventing some new magic features on the fly (e.g. a mashup using the Twitter API, GoogleMaps API and maybe Zappos API), showing off your cool new "product" to a few people and then writing up a simple "specification" and list of "test cases" and turning that over to Mechanical Turk for testing. (Extra points are awarded for believing your product is then next Facebook, Twitter or YouTube.)
share|improve this question
defect driven development - we are sometimes forced to follow this when the stakeholders wants to do a 1 year project in the span of 3-4 months keeping everything constant. ;-) –  Pangea Dec 26 '10 at 9:51
@Pangea: and why can't you just do it? It's just code... (sarcasm) –  cherouvim Dec 26 '10 at 10:02
For me TDD is an "add on" or aspect that can be appied to many softwaredevelopment domains Waterfall, Agile, Scrum, oop, functional programming. The only alternative is to use it or not to use it. I would replace "... that are TDD ...." with "... that do not use/need/require TDD ..." –  k3b Dec 26 '10 at 11:00
add comment

3 Answers

up vote 4 down vote accepted

Cleanroom Software Engineering is a methodology that sounds on the one hand extremely rigid, static, "un-agile" and pretty much the opposite of TDD, but on the other hand it is actually very similar. It is highly iterative for example, like all Agile methods. Like TDD, you write a specification first, but unlike TDD that specification takes the form of a mathematical proof of correctness rather than an executable test.

Where the TDD cycle is

  1. Specify
  2. Code
  3. Refactor
  4. Demonstrate correctness through executable specifications

The Cleanroom cycle is

  1. Specify
  2. Code
  3. Refactor
  4. Prove correctness
  5. (Test)

I put the tests in parentheses because they are usually (semi-)automatically generated from the specification. So, while they are part of the development cycle, they are not part of the work the programmer has to do.

From what I've read, the performance metrics of Cleanroom are very similar to those of TDD, which leads me to believe that the real value of TDD isn't actually in the testing part, it is in the thinking part. It would be interesting to perform an experiment, where you replace the "Red" part of TDD with a simple stopwatch that locks your keyboard for 30 seconds before you can write a new method.

share|improve this answer
I believe that you are right! It is important reinforce developer discipline to "THINK about the requirement FIRST" ... either TDD [or Cleanroom] ... more important than in the mechanics/automation of testing. –  markbruns Dec 26 '10 at 11:38
add comment

There are cases were automatic testing is just not relevant or can't be implemented:

  • Interactive User Interface is generally very hard to test automatically, many things are actually dependent on real user experience and it is hard to test it without real human being - QA.
  • Some stuff can't be "measured" or "tested" but rather relay on human being for test. For example when you develop a kind of image processing algorithm that should be embedded in some device, it is very hard to define what is "correct" approach or even measure it. Not talking about that some cases are very hard to test.

I would say there are many cases that can't be covered with automatic scripts that do the job - most require human skill human reaction and quality estimation.

There are perfectly valid to not being tested automatically.

share|improve this answer
I just started to type "Gui-Design using Rapid Prototyping. You cannot create automated tests for it" but your answer was faster :-) –  k3b Dec 26 '10 at 10:58
Thanks for your answer, but I am not sure I understand. Are you saying that TDD tests are exclusively automated? Even when we can't automate a test, can't we still write a test or a work instruction that would be evaluated by a human? My understanding of TDD allows for tests that cannot be automated -- the key of writing tests first is to build the discipline of understanding the requirements in sufficient detail prior writing code -- perhaps my understanding of TDD is flawed. –  markbruns Dec 26 '10 at 11:25
add comment

defect driven development - we are sometimes forced to follow this when the stakeholders wants to do a 1 year project in the span of 3-4 months keeping everything else constant. ;-)

This actually worked out pretty well. No waiting for requirement completion, QA is getting early builds, stakeholders are engaged in resolving issues from beginning to the end (as QA/dev doesn't have enough information at their disposal). The only flip side is there is no refactoring. But hey, if the users are happy and the product is out in just 3 months thus saving lot of money the refactoring/SOLID principles doesn't matter much...But only if the original developers are gone then maintenance becomes a pain in the neck.

share|improve this answer
This answer sounds a little too familiar ... I'll vote this answer up because making the best of a crappy situation is not necessarily the smartest thing to do, not necessarily the right thing to do, it what makes us who we are. As the Stones would say, "You can't always get what we want, but if you try sometimes, you might find, you get yourself kneed." –  markbruns Dec 26 '10 at 10:20
add comment

Your Answer


