Object Mentor Blog: Not A Task, But An Approach

Not A Task, But An Approach

Tim Ottinger — Thu, 02 Aug 2007 22:14:00 +0000

Transitions are tough. It seems that lately I’ve been getting a lot of contact from frustrated people who don’t really have a good handle on the “drive” part of Test Driven Development. A question heard frequently is: “I’ve almost completed the coding, can you help me write the TDD?”

It seems like Test Driven Development is taken backward, that the developers are driven to write tests. The practitioner winces, realizing that he again faces The Great Misunderstanding of TDD.

TDD stands for Test-Driven Development, which is not as clear as TFD (Test-First Development). If the consultant would strive to always say the word “first” in association with testing, most people would more surely grasp the idea. In fact, I’ve begun an experiment in which I will not say the word “test” without the word “first” in close approximation. I’ll let you know how that works out for me.

If the tests are providing nothing more than reassurance on the tail end of a coding phase, then the tests aren’t driving the development. They are like riders instead of drivers. Test-Ridden Development (TRD)[1] would be a better term for such a plan. Even though it is better to have those tail-end tests than to have no automated testing, it misses the point and could not be reasonably be called TDD.

An old mantra for TDD and BDD is “it’s not about testing”. The term BDD was invented largely to get the idea of “testing” out of the way. People tend to associate “test” as a release-preparation activity rather than an active approach to programming. BDD alleviates some of that cognitive dissonance.

In TDD, tests come first. Each unit test is written as it is needed by the programmer. Tests are just-in-time and are active in shaping the code. Acceptance Tests likewise tend to precede programming by some short span of time. [2]

Through months of repetition I have developed the mantra:

TDD isn’t a task. It is not something you do. It is an approach. It is how you write your programs.

I wonder if we shouldn’t resurrect the term Test-First Programming or Test-First Development for simple evocative power. Admittedly there are some who would see that as a phase ordering, but maybe enough people would get the right idea.

Brett Schuchert(with some trivial aid from your humble blogger) has worked up an acronym to help socialize the basic concepts which are somehow being lost in translation to the corporate workplace.

The teaser: Fast, Isolated, Repeatable, Self-validating, and Timely.

As a reader of this blog, you are probably very familiar with all of the terminology and concepts behind TDD. I beg of you, socialize the idea that testing comes first and drives the shape of the code. If we can just get this one simple idea spread into programming dens across our small spheres of influence, then we will have won a very great victory over Test-Ridden Development.

“And there was much rejoicing.”

1 Jeff Langr will refer to this TRD concept as “Test-After-Development”, which he follows with a chuckle and a twinkle, “which is a TAD too late.”

2 Of course, one still needs QC testing as well, however TDD is about driving development, not testing its quality post-facto.

"Not A Task, But An Approach" by Susan

Mon, 02 Jun 2008 07:23:17 +0000

Im newbie here, thank you all!

"Not A Task, But An Approach" by Nathan Henkel

Mon, 20 Aug 2007 11:40:53 +0000

One problem I have with using the term “Test-First Development” is that I think it loses information compared to the term “Test-Driven Development”. The first simply suggests to me that I write tests before code (which is good), the second suggests that I write tests before code AND allow my tests to drive the design of my code, so I’m doing the “simplest thing” that will pass my tests.

With test-first development, you might write some tests, and then write the code you “know” you’ll need (because you’re being driven by a preconceived design, or intuition, or cast bones), which happens to DO more than your tests actually verify. Now you have untested functionality. True TDD tells you to write the simplest code that will pass your tests, write new tests to demonstrate the inadequacies of that code, rewrite or add to the code to pass those tests and so on until you can’t think of any more useful tests. The tests are driving your coding, so, theoretically, you won’t have any untested functionality, and practically you’ll have very little.

I do get the problem of making sure people understand that the tests have to come FIRST—how can they drive when they’re sitting in a trailer hitched to the back? On the other hand, putting them in the passenger seat or strapping them to the hood isn’t quite right either. Maybe not abbreviating is the answer, or perhaps emphasis: “test DRIVEN development”...

"Not A Task, But An Approach" by Dean Wampler

Wed, 08 Aug 2007 10:38:06 +0000

Just a bit more about Behavior-Driven Development (BDD); Dan North coined the phrase. Here is his article introducing BDD. There are now rbehave and jbehave tools for driving development at the requirements/story level, while rspec is focused more on the “unit” level.

"Not A Task, But An Approach" by Tim

Tue, 07 Aug 2007 09:14:14 +0000

vabhav: certainly. You can’t drive the code without working on the code.

Test-last development won’t have the same effect, and rather will force you to spend a lot of time and effort writing runnable tests, rather than writing testable code.

"Not A Task, But An Approach" by vabhav jain

Tue, 07 Aug 2007 01:38:22 +0000

I am 100% agree but the follow the apporach you need to work on task

"Not A Task, But An Approach" by Tim

Mon, 06 Aug 2007 19:56:46 +0000

TDD helps developers understand requirements (or at least correct misunderstandings early).

I don’t know why you think that they analyze all requirements before writing any code.

My experience is that one may look over the requirements (AKA “Acceptance Tests”) in small sets, but often doesn’t do a lot of “long range analysis”. Frequently the developer knows quite a bit because he has participated in the planning sessions and has helped estimate the story, but sometimes the AT is enough. Then there is the TDD three-step dance of one little test, one little change, one burst of refactoring.

As to how it changes the shape of your code, this is lightly touched upon in an earlier referenced post. Generally, though, you will write the code intentionally to be (unit) testable. from the very start. That implies a lot of things.

"Not A Task, But An Approach" by Anand

Mon, 06 Aug 2007 15:53:33 +0000

See, as i understtod, TDD helps developer understanding requirements before coming up with code, and because they are going to write Unit test cases, they will certainly analyze each and every piece of requirement before writing a single line of code. But can you telle me, how it affectes our design, like which design pattern, and granularity of code?An example may be of more help.

"Not A Task, But An Approach" by Tim

Mon, 06 Aug 2007 10:29:39 +0000

BDD is “Behavior Driven Design”, and is a further development of TDD. If you look at RSpec, you will see the current state of development of BDD. David Chelimsky and Dave Astels seem to have the lead on this.

"Not A Task, But An Approach" by Bill

Mon, 06 Aug 2007 09:14:51 +0000

Ok, It’s Monday and I’m running a bit slow, what is BDD? Note Google wasn’t much help offering up:

Behaviour-Driven Development

Business-driven Development

Backup Driven Development

to name a few.

"Not A Task, But An Approach" by Jeff L.

Sun, 05 Aug 2007 13:38:54 +0000

“A chuckle and a twinkle?” I guess I’m Santa Claus.

"Not A Task, But An Approach" by Tim

Fri, 03 Aug 2007 07:31:23 +0000

I think you are right. I think I can do better.

Clearly I am trying to say in that one throwaway line that test-first will change how we make decisions about our code (which patterns we’ll use or avoid, how much the code exposes state, how granular we make our functions, how much we rely directly on other objects, etc). In short all the things from my earlier posting and more.

But that’s not what I said, and what I said can certainly seem an overstatement. I will make revisions.

"Not A Task, But An Approach" by Sadek Drobi

Fri, 03 Aug 2007 01:55:30 +0000

I agree with most of what you said, but not completely on ” drives the shape of the code.” I guess that this is confusiong, and needs a bit of clarification… see: It is NOT a test driven design!