my dog learned polymorphism*
The moose likes Agile and Other Processes and the fly likes test driven approach Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "test driven approach" Watch "test driven approach" New topic
Author

test driven approach

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
What is test driven approach?

Is it writing tese case beforehand code?

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�
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: test driven approach