Code or Test first ?

[Balaji Loganathan]

I am still a beginner in this Agile world, so please pardon me if this question sound stupid.

What is your perspective on
"Write the Code first, then write Test" or
"Wrtie the Test first, then write the Code"

Thank you.
Regards
Balaji

[Lasse Koskela]

I'm writing a book on Test-Driven Development. It's currently over 300 pages. Considering all the revisions I've made, I've probably written that 300 pages twice by now. Wanna guess which of the two I'm personally in favor of?

[Balaji Loganathan]

Let me guess...
Write the test first, then write the code ???

[Lasse Koskela]

Yes, I definitely think TDD helps me develop better software than the traditional test-after approach.

[Lasse Koskela]

Originally posted by Lasse Koskela:
Yes, I definitely think TDD helps me develop better software than the traditional test-after approach.

And having said that, I have also seen plenty of developers who have thought the exact opposite ("I don't need TDD"). Although that opinion has almost always been based on zero first-hand experience.

[Jeanne Boyarsky]

I'm in the "Write the Test first, then write the Code" camp, but not quite as securely as Lasse. I do TDD about 75% of the time. On standalone code and bug fixes, I always do TDD.

However, when I am writing a class that has the API set by our framework and is very short/simple, I tend to jump ship. I think this is because I already have the code in my mind. Writing the tests wouldn't make it TDD, it would make it more like "happened to write the tests first."

When I started doing TDD, I did it about 5% of the time. I tried using it on all code before I was ready and then forgot about it while I was coding. After a while I started just using it on standalone code. Then I gradually added. So like anything new, it felt awkward at first.

[Ilja Preuss]

Jeanne, when you don't do TDD, does that mean that you

"write the code first, then write the test",

or do you fully skip the tests?

In my experience, writing tests for existing code is just so much harder that I can't think of it as a good alternative to TDD...

[Frank Carver]

Ilja wrote: Jeanne, when you don't do TDD, does that mean that you
"write the code first, then write the test", or do you fully skip the tests?

I think there is another case, which I reckon even experienced TDD-ers slip into from time to time: "write the test in your head, then write the code".

One of the main benefits of TDD is that design is always aware of the needs of the tests. This is so powerful that after a while it's hard to design without thinking of how something will be tested. It could well be that when Jeanne talks of "writing a class that has the API set by our framework and is very short/simple", the code is actually written as if the tests are there, but the tests are never run because they don't actually exist.

Sure, this approach does not get the long-term benefits of TDD (catching typos and misunderstandings, a growing regression suite, executable documentation of how to use the code, etc.) but it still has some design value. If there can be said to be a "half-TDD" process, this might be it.

As a known TDD-booster, Ilja, do you ever find yourself doing something like this?

[Rahul Bhattacharjee]

Writing programs strictly to interfaces would enable you to write the test first and then the concrete classes.
And I think this is a good practice , we practice this in our organisation.

[Ilja Preuss]

Originally posted by Frank Carver:

As a known TDD-booster, Ilja, do you ever find yourself doing something like this?

I don't think so.

Frankly, I don't do as much TDD as I should - I'm a lazy, undisciplined bastard.

But the real work for me is in the thinking, not in the writing. So when I skip the test I mostly skip the thinking, not the writing. If I invest the time to think about how to test something, I can as well just write the test. In fact for me the easiest way to think about how to write a test for something is to just write the test - it's much harder for me to do it as a dry run, because I have to keep so much more in memory instead of simply dumping the thoughts into the source code, so to speak...

[Peer Reynders]

Originally posted by Rahul Bhattacharjee:
Writing programs strictly to interfaces would enable you to write the test first.

That is sometimes not enough. Often you need to also resort to dependency injection so that it is even easier to control the dependencies of the unit under test. Also the interfaces often need be designed in the spirit of Dependency Inversion (The Principles of OOD).

But designing/implementing to interfaces is certainly a good first step.
[ November 10, 2006: Message edited by: Peer Reynders ]

[Mary Poppendieck]

It's been a while since I've coded, so I can't remember which I did first. However, I did most of my programming in the hardware control world (embedded software these days, but computers were bigger then). I always wrote a simulator to test the logic of my code, so that when I flew to remote places to install my software onto the hardware, I could get back home to my family as fast as possible.

Another thing one typically does with embedded software is to write a very simple logging mechanism that triggers differently depending on whether it is running on the target hardware or the development machine, so you can always tell what is going on as hardware is introduced.

Bottom line, there are different approaches for different domains, but testing virtually as soon as the next bit of code is written and integrating as early and often as possible is essential. This causes you to think about how to test as part of the overall design, which gives you testable code.

Mary Poppendieck

[Stan James]

I'm writing a book on Test-Driven Development.

So now it's write the test first or the code first or the book first?

I wish I could properly attribute these three rules ... it was on ButUncleBob.com but not sure which author.

1) Write production code only to make a failing test pass
2) Write only enough test to make it fail
3) Write only enough production code to make the test pass

That's pretty explicit and extreme on write the test first. I think that would be very hard to do 100% of the time.

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
Jeanne, when you don't do TDD, does that mean that you

"write the code first, then write the test",

or do you fully skip the tests?

No! Of course I don't skip the tests. I didn't mean to imply that. I know what both the code and tests look like in my head from writing that type of method so many times. They both pop into my head at about the same time. Maybe I should say I type the code before the test.

In my experience, writing tests for existing code is just so much harder that I can't think of it as a good alternative to TDD...

I guess I don't consider just writing the tests first to be TDD. The tests aren't driving much of anything if I already know what the completed product will look like.

[Jeanne Boyarsky]

Originally posted by Frank Carver:
It could well be that when Jeanne talks of "writing a class that has the API set by our framework and is very short/simple", the code is actually written as if the tests are there, but the tests are never run because they don't actually exist.

The tests are run before I try out the code or go on to another method. They just happen to get typed in later than the code.

Originally posted by Frank Carver:
Sure, this approach does not get the long-term benefits of TDD (catching typos and misunderstandings, a growing regression suite, executable documentation of how to use the code, etc.) but it still has some design value. If there can be said to be a "half-TDD" process, this might be it.

Since the tests are written it catches typos and forms a regression suite. It doesn't catch misunderstandings or create executable documentation because the framework is already ingrained.

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:
No! Of course I don't skip the tests.

Well, then you must be much more disciplined than me...

I guess I don't consider just writing the tests first to be TDD. The tests aren't driving much of anything if I already know what the completed product will look like.

To me, the tests don't only drive the API, but also the implementation - even if I think I already know what it should look like.

I also get a lot of joy from making a test pass that failed beforehand. If I have to write the test anyway, I wouldn't want to miss that...

[Jeanne Boyarsky]

Originally posted by Ilja Preuss:
even if I think I already know what it should look like.

There isn't a whole lot of variation in "return myForm.getInputId();"

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

There isn't a whole lot of variation in "return myForm.getInputId();"

True. Might be one of the occasions where I'd totally skip the test...

[Lasse Koskela]

Originally posted by Stan James:
So now it's write the test first or the code first or the book first?

You start by writing a test, then write the same test in the manuscript, then make the test pass as quickly as possible, then write the same implementation to the manuscript, then ...

Originally posted by Stan James:
I wish I could properly attribute these three rules ... it was on ButUncleBob.com but not sure which author.

1) Write production code only to make a failing test pass
2) Write only enough test to make it fail
3) Write only enough production code to make the test pass

That's pretty explicit and extreme on write the test first. I think that would be very hard to do 100% of the time.

Most of the time, people doing TDD fluctuate around their comfort zone in terms of granularity of their steps (tests). You start with a small test, over time you start taking bigger and bigger tests, and then you get burned and remember why it's important to take small steps.

And I do slip from TDD every so often. The important thing is that I become painfully aware of such a slip and quickly get back to the saddle.

[Lasse Koskela]

Originally posted by Jeanne Boyarsky:
There isn't a whole lot of variation in "return myForm.getInputId();"

The need to write routine-like code is often a sign of duplication in the code base. Perhaps some of this stuff could be done dynamically, possibly using reflection?

[Jeanne Boyarsky]

Originally posted by Lasse Koskela:

The need to write routine-like code is often a sign of duplication in the code base. Perhaps some of this stuff could be done dynamically, possibly using reflection?

Normally the method implementation is more complex or at least longer. I picked the simplest case as an example of what we were discussing.

What the method does is to take Struts fields and store the relevant ones in a DTO. Often there is actual logic in translating what the user entered to what is needed by the next layer.

Even for the simple case where we are just copying a single field, the name of this field would have to be somewhere. So we are back to having something that needs testing.

[Peer Reynders]

What about when you are writing Spikes/Tracer Bullets?

There definitely would be the temptation to simply code ahead because you are simply trying to figure out if something is possible, or how hard it's going to be.

However under the right circumstances writing test-first code even under these circumstances may be beneficial as the tests would likely capture (ahem, document) what has been learned much more effectively. Also it forces you to define what possible observable effects you are actually looking for and possibly what side effects you do not want to see.

(The assumption being that "code first"/"test later" would never happen when you are working on Spikes/Tracer Bullets.)
[ November 14, 2006: Message edited by: Peer Reynders ]