Not A Task, But An Approach 11
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.
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!
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.
“A chuckle and a twinkle?” I guess I’m Santa Claus.
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.
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.
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.
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.
I am 100% agree but the follow the apporach you need to work on task
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.
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.
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”...