Test driven development

[Pradeep bhatt]

Hi all,

TTD - You write a test that fails before the functional code is written. How do I test before the code is written?

Suppose I want to test a method convertCurrency, do I write an empty method and test.

public float convertCurreny(float fromCurrency)
{
return -1; //no logic written  returning -1 so that the test fails, right?
}
 

The above method will fail because I have not written the fucntional code. Is it the way to test?


Is TTD part of XP? Or is it independent ?

Is TTD all about Unit Testing.

Thanks a lot!
Pradeep

[Ilja Preuss]

Originally posted by Pradeep Bhat:
TTD - You write a test that fails before the functional code is written. How do I test before the code is written?

How can you write a method without knowing it's signature and behaviour?

Suppose I want to test a method convertCurrency, do I write an empty method and test.

You write the test. The test will fail to compile, because the method doesn't exist. Now you write an empty method definition (in Eclipse, just press ctrl-1 on the compile error). Now the test will fail to run.

Is TTD part of XP? Or is it independent?

TDD is one of the techniques of XP and probably got well known because of this fact - but it already existed before, as far as I know, and can easily be used with any other method. It works best if you are allowed to adjust the design while writing the code, though.

Is TTD all about Unit Testing.

Depends on whom you speak too. Many will understand it that way, but recently there has been a move to write Customer Tests first too, and therefore tend to include them in the notion of TDD.

[Pradeep bhatt]

Thanks for the reply.

How can you write a method without knowing it's signature and behaviour?

What does not writing functional code mean as per TTD definition. I was under the impression that we dont write the code inside the method i.e. write empy methods.

What is the use of writing a test that fails before the functional code is written?

Can I say that TTD is one of the ways to implement XP?

Thanks again!

[Ilja Preuss]

Originally posted by Pradeep Bhat:
What does not writing functional code mean as per TTD definition. I was under the impression that we dont write the code inside the method i.e. write empy methods.

We start by writing the test because that helps us discover what API we actually need. It helps us taking the point of view of the client when deciding about the interface of the class under test.

What is the use of writing a test that fails before the functional code is written?

Every now and then it happens that a new test actually doesn't fail - because there is a bug in the test, because the production code already is doing what you want it to do, or because you actually did run the wrong test.

That's important enough feedback that we make a habbit of always observing a test fail before making it run.

Can I say that TTD is one of the ways to implement XP?

I'm not sure I understand what you mean by that phrase.

I'd say that TDD is *the* practice proposed by XP for implementing the production code.

[Pradeep bhatt]

Thanks Ilja for you answers.

[Stan James]

A tiny addition ... writing a test to an empty method or a method that is hard-coded to return the correct answer for the simplest case is seen in a lot of TDD examples. This tells you the test is properly set up and running, which is a non-trivial milestone your first day with JUnit and worth checking every time.

[Pradeep bhatt]

I have read many books that coding and unit testing involves only 15% of the project. If this is true why is TDD given so much importance in XP?

[Tony William]

I have read many books that coding and unit testing involves only 15% of the project. If this is true why is TDD given so much importance in XP?

Part of the reason that I can think of is TDD really gears the developers towards what they need to do and can discover problem / bug in early stage of the development.

[Jared Richardson]

Originally posted by Pradip Bhat:
I have read many books that coding and unit testing involves only 15% of the project. If this is true why is TDD given so much importance in XP?

People are realizing that TDD is more about designing your code properly and less about testing it.

[Scott Ambler]

I have read many books that coding and unit testing involves only 15% of the project. If this is true why is TDD given so much importance in XP?

You need to step back and ask what context that advice was given. This is a serious problem in the IT industry right now. There is a lot of material out there written in the context of traditional development. What makes sense in that context might not make sense in another.

For example, at Model Reviews: Best Practice or Process Smell? I argue that model reviews made sense in traditional environments but don't really make sense in environments where you're taking an AMDD approach. Yet, I could easily dig up research information (and I have) which shows that model reviews are a really good idea -- they often are when you're not taking an AMDD approach.

- Scott

[Pradeep bhatt]

Hello Scott,

This article http://martinfowler.com/articles/newMethodology.html contains

Another issue is that of comparative cost. When you build a bridge, the cost of the design effort is about 10% of the job, with the rest being construction. In software the amount of time spent in coding is much, much less McConnell suggests that for a large project, only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work. This raises an important question about the nature of design in software compared to its role in other branches of engineering.

Is my understanding wrong here ?I am yet to completely read the article. Thanks.

[Jeanne Boyarsky]

Pradip,
Your understanding is correct. The 15% figure comes from that if the requirements are wrong it doesn't matter how correctly you implemented them.

TDD is one of the most known XP practices because it is one of the easiest to use if you are using a non-XP methodology. Even one developer can do TDD without getting everyone to do so.

However TDD != XP. XP has many other processes that deal with the other 85% of the project. For example, user stories help with requirements.

[Pradeep bhatt]

Jeanne ,

Thanks. What are stories ? Is it a Use Case ?

[Jared Richardson]

Originally posted by Pradip Bhat:
Jeanne ,

Thanks. What are stories ? Is it a Use Case ?

A Use Case is a description of how your users will use your software. These are descriptions that your customers can read, understand and (hopefully) agree to as a good description of what they need.

Then you use the Use Cases (or stories, scenarios, etc) to describe the product to your developers.

Ron Jeffery's XP site is a little slanted towards his personal views, but it's a great information source. Check it out here.

Here is the first Google hit on "xp 'use cases'".

[Jeanne Boyarsky]

User stories are typically smaller and less formal than a use case. A use case may involve finding a book and buying it (one use case from the user's point of view.) A user story may be searching for a book. Also, a use case tends to group the exception cases with the use case. Meanwhile a user story would treat them as a different story.

[Pradeep bhatt]

Thanks Jared for the useful links.

Jeanne,

Thanks. Can I say an UseCase is a collection of stories. In you example "Searching for a book" is part of "finding and buying the book". Also an exception case is also an story ?

[Tony William]

sound like to me that:

A use case can tell many stories. On the other hand, combining many relevant storis may not form a use case as there are other kinds of pieces in a use case like the pre-condition, post-condition, special / non-functional requirement etc.

[Ilja Preuss]

Originally posted by Pradip Bhat:
Can I say an UseCase is a collection of stories.

Not really. They are more like quite different ways of tackling the problem of requirements elicitation. Most people don't actually mix the two.

Also an exception case is also an story ?

Not necessarily. Might depend on the size of the story, the importance and size of the exception case, and on wether it will be scheduled independently. It might just be communicated later during the discussion in the iteration planning meeting and formulated in a test case.

[Jeanne Boyarsky]

Originally posted by Pradip Bhat:
Can I say an UseCase is a collection of stories?

You can say a use case is typically broader than a user story. As pointed out, it isn't a "contains" relationship though.

[Fintan Conway]

Originally posted by Pradip Bhat:
Hello Scott,

This article http://martinfowler.com/articles/newMethodology.html contains




Is my understanding wrong here ?I am yet to completely read the article. Thanks.

Hi Pradeep,

In XP there is NO design phase, per se. eXtreme Programmers believe that the design evolves as the code is developed. They use TDD as the means to develop the code, without going through a formal design phase. Therefore, TDD incorporates the 15% Code & Unit test + 50% Design = 65% of the overall process!

Regards,

Fintan

[Ilja Preuss]

Originally posted by Fintan Conway:
In XP there is NO design phase, per se.

Notice that this doesn't mean that there is no up front design done at all. XP teams typically have design discussions in the release and iteration planning meetings, and shortly before starting to implement a feature. They might even do some prototyping (often called "spikes") to evaluate a design idea.

[Francis Siu]

Originally posted by Pradip Bhat:
Can I say an UseCase is a collection of stories.

I think that a Use Case could be a story or a collection of stories that describe the events and processes

Also an exception case is also an story?

I think that exception case could be a branch or a collection of branches for that story.
And the story may be better to be defined by EBP guideline

[Ilja Preuss]

Originally posted by siu chung man:

I think that exception case could be a branch or a collection of branches for that story.
And the story may be better to be defined by EBP guideline

A "branch" sounds a little bit too formal to me. A story doesn't get very formal until it gets expressed in acceptance tests. Might even be that that is the first point in the lifetime of the story that the exceptional case gets formulated explicitely.