aspose file tools*
The moose likes Agile and Other Processes and the fly likes Code or Test first ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Code or Test first ?" Watch "Code or Test first ?" New topic
Author

Code or Test first ?

Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
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


Spritle Software Blogs
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
Let me guess...
Write the test first, then write the code ???
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Yes, I definitely think TDD helps me develop better software than the traditional test-after approach.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30928
    
158

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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?


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Rahul Bhattacharjee
Ranch Hand

Joined: Nov 29, 2005
Posts: 2308
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.


Rahul Bhattacharjee
LinkedIn - Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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
author
Ranch Hand

Joined: Oct 04, 2006
Posts: 62
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


Mary Poppendieck
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30928
    
158

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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30928
    
158

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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30928
    
158

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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30928
    
158

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
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Code or Test first ?