Bill Gates CES 2008 Keynote

7 01 2008

winvista-button_rgb.jpg

You can watch it here

(Don’t miss the video – Last day @ Microsoft 😉 )

Advertisements




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
{
    [TestFixture]
    public class SimpleTests
    {
        [Test]
        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