I am TDD :)

7 01 2008

TDD isn’t really a new phrase. Its the acronym of Test Driven Development πŸ™‚

I was introduced to TDD by my friend Ivan and now I firmly believe that TDD is the right development technique and practice that every developer should acquire.

Normally, we are taught the general development principle – “Design, Code, Test, Release (DCTR)” – This is the Model which most of the developers/companies follow. But with TDD it becomes – “Test, Code, Design“. What is the big difference here? Yes, there is. With the DCTR approach, your whole development process depends on the design and you strictly follow the design to release the product. The problem comes when there is a need to alter the design and change the code. It becomes very difficult here as your code and design are tightly coupled to each other. With TDD, you write tests for what your application has to do, which ultimately will lead you designing your application.

From Wikipedia,

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.

Many now may have this feeling – “I am a Developer and why should I write test cases and test it! Let the Tester do it” – Its quite natural to get this feeling πŸ™‚

But the TDD approach ensures that the code a developer writes is proper, well structured and BUG FREE. The only way to achieve this is to have Unit Test run on the code we write to see whether we are getting the right job done. If the tests fail, you can easily debug it and make it pass πŸ˜‰

Here is an example (I am using NUnit for Test Framework)

– Lets say you want to write a function to add two numbers. It takes two integers and returns the result back to you.

With the TDD approach we first write a test for this

namespace SampleTests
    public class SimpleTests
        public void Check_Method_Add_Return_Result()
            Test myTest = new Test();

            int nExpectedResult = 4;
            int nResult;

            nResult = myTest.Add(2, 2);

            Assert.That(nResult, Is.EqualTo(nExpectedResult));

It looks fairly simple, isn’t it :). There isn’t any magic going. I have an expected result and the result variable. I am going to call the Add function and get the result. If the expected result and the result which Add function gave are same, then it has added it properly πŸ˜‰

So, now you go write your Add function and run the test case to see if your test succeeds

public class Test
    public int Add(int n1, int n2)
        return (n1 + n2);

This is very very simple example , but I do think its a good place to start. I would suggest writing small programs first and then slowly incorporate the TDD style in your projects.

Some of the tools (for .NET) you might need are,

1) NUnit

2) TestDriven.net

3) RhinoMocks

4) Resharper

And last but not the least, a good read at Martin Fowler’s articles πŸ˜‰

In the coming days, I would go further into TDD




3 responses

10 01 2008

I have actually stopped testing my apps. The good news is that since I stopped testing my apps, my reported bugs have gone way down. πŸ™‚

Nice blog entry, Chak

12 01 2008

Thanks David for the comment πŸ™‚

I am really happy to see you here πŸ˜€

Hats off to you for running the Community Credit website!

3 04 2008
Owen Evans

Hi Chak,
I’m reading from the bottom of the TDD category up so I’m going to comment on this one and then read the rest :).

first off i have to put a real big warning to those reading this getting into TDD. Test Driven Development is not a golden chalice.
Test driven development, rather than being about the act of testing is about the act of verifying design decisions in a repeatable way. If functionality changes you know immediately where else you’ve effected (look at all those red lights!)
It DOES NOT produce bug free software (actually I’d challenge anyone to come up with bug free software) what it does produce is software that works as expected given certain criteria. the failures usually come from extreme or unusual circumstances, unspecified uses, and unexpected environments.

The bonus is that bugs are made a lot easier to fix, and keep the same functionality.
It’s essentially a refactoring safety net.

but good on you for getting into it, i think it’s a great tool to have in ones arsenal (along with continuous integration IMHO)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: