test driven approach

Suppose I have to write a method that calculates tax for any item based on its properties:

public float calculateTax(Item item) {

}

Now if I write JUnit test case (what else other than JUnit?) before writing logic for this method:

Now I write calculateTax() method. Run this test, it shows green � cool so far.

But what advantage did I get from this? Couldn�t I run this method in a debug mode and verify its correctness? Is it developed as a proof to others that my code is working fine? What if I made mistake in writing test case?

I read somewhere that its useful when you change your code later on � run the test suite and verify if all test cases are passed or not�

If I change calculateTax() method�s logic or any other method which is being used by this method, in future, then this test case is supposed to fail. I must, first, change this test case (specifically expected value) and then run the test suite�

Originally posted by ankur rathi: Couldn�t I run this method in a debug mode and verify its correctness?

Sure you could.

Note that TDD is not only a testing strategy, but also a design strategy: the test code is a form of client code. By writing the test code first, you start by thinking about the interface of the production code from a client perspective first, and only later from an implementation perspective. That typically leads to a cleaner API.

Also, writing tests first naturally leads to easier to test code (because the production code API is written with a focus on testability). Code that is easy to test in isolation (which unit testing is) needs to be well decoupled code, which is a property we generally want to have in a good design.

Is it developed as a proof to others that my code is working fine?

That's not my focus. I'm mainly doing it for myself. And being good at both writing JUnit tests and debugging, I'm actually convinced that writing the tests is faster, easier and more fun.

Having said that, good unit tests are often also good *documentation* for what the code is supposed to do.

What if I made mistake in writing test case?

For the test to pass, you had to make *exactly the same* mistake in the production code, too. That's highly unlikely. In it's essence, unit tests and production code state the same thing in very different, redundant ways. If both agree with each other, you can be quite sure that they do what you intended them to do. What those tests won't find, of course, are things that you forgot to test for, or that you totally misunderstood. (Pair Programming is of some help in those cases.)

I read somewhere that its useful when you change your code later on � run the test suite and verify if all test cases are passed or not�

If I change calculateTax() method�s logic or any other method which is being used by this method, in future, then this test case is supposed to fail.[/QB]

Not necessarily.

In your example, you indicated that there are 4-5 more properties that affect taxes. (That would probably mean that there should be more than one test already, testing different combinations. And following TDD, you wouldn't just first write all those tests and then the production code, but alternate between them.)

Now imagine that there is a new requirement for another property that should be added. For items that don't have that property, the rules stay the same. So all the old tests should still pass. You just add a new test, add the code to make that test pass, and validate that you didn't brake any of the old tests.

Having implemented that new case, you might suddenly get the idea of a change in the algorithm that makes it more elegant, and might it even make easier to add new cases in the future. When you don't have automated tests, applying such a change is very risky. With an extensive test suite in place, you can get immediate feedback on whether the change broke something in a matter of seconds.

In my experience, that fundamentally changes what changes you are able to do to your code. It enables the change from a "don't touch a running system" to "hell, let's just try it, and revert it if it doesn't work".

Does that help?

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

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com