Java(TM) Boutique - Tutorial - Deliver Your Code with Confidence Using Test-driven Development

Tutorials : Deliver Your Code with Confidence Using Test-driven Development :

Failures Are the Pillars of Success

Unlike the traditional testing point of view, in TDD, you first write the test with the idea that it must fail. So the objective becomes to make the failed test pass. One beneficial side effect of this approach is that code becomes thoroughly unit tested. TDD does not preclude any other testing requirements and you'll still carry on doing the integration test, user acceptance test, etc. Since the code is first thoroughly unit tested, the degree of confidence that any module will pass a user acceptance test is very high. TDD is based on two important principles, as preached by Kent Beck—the originator of this concept:

Write new business code if only an automated test has failed: Using this model, the business/application requirements drive the tests and tests drive the actual functional code. Hence, any change in requirements will first impact the tests (typically some pre- and post-conditions) and in order to pass the new test, code will need to be re-adjusted. But again, as you do not stop before all the tests pass, the new code is also unit tested and the degree of confidence remains the same that the new code also will function with equal correctness.
The above principle functionally means that you are not writing the tests to examine the validity of the code but you are writing the code to justify the test.
Eliminate duplication from the code: This princicple impacts the quality of the internals of the code. A particular business concept should implemented once and only once within the application code. A simple example is that the code for checking hotel room availability should be centralized to only one place within the code. By eliminating duplication form the code, the design becomes highly decoupled and re-usable.

Design and TDD

TDD is an iterative process. At each stage, writing the tests and running them provides significant feedback about the quality of the design and code. Any project needs the high-level design to be ready before you can start development. But the lower-level design moves in tandem with the development in the TDD approach. With TDD, while writing the tests, you get valuable feedbacks about the validity of the high-level design. It is immensely helpful to discover any defects at such an early stage of a project.

Following the Design by Contract methodology helps in achieving TDD. In Design by Contract, you specify the pre- and post- conditions as contracts of a method. So you have clear specifications to write the tests against. For example, take the following method definition in the design phase:


@precondition: memberID is an integer
                        memerID is valid.
@postcondition: List of books issued by the memberID
                          empty if none.
public List getBooksIssued(Integer memberID) throws SomeException

Now you know that you have to write tests for all the preconditions and postconditions and also for the exceptions. So Design By Contract helps TDD. Also, TDD helps keep the focus on the testability of the interfaces.

Here's another example. Suppose you have two tests for an ATM application:


testWithdrawMoney() and
testDepositMoney()

Say the the design defines a method called:


transactMoney(Boolean transactionType, double acctBalance, double amt)

This method covers both withdrawal and deposit, but you might make it more cohesive by splitting it into two separate methods for withdrawal and deposit. This makes your tests a lot easier to write. As a result, the system will be more maintainable. Notice that this desgin flaw was detected by trying to write and complete the tests. This is why TDD is so useful—it provides feedback at all stages about the quality of the design.

If any of your tests fail, you simply re-factor the code. After re-factoring, you run the tests again—or the whole test suit to see all the tests pass. Using the TDD approach, re-factoring is easier and can be done with more confidence.

In another example, assume you are writing a code which takes input from an external device. When the external device is not present, you need to create an interface, which takes input from another source in order for your tests to work. This forces an interface-based design, in which there are multiple implementations and you use one or the other depending upon the situation. You must use this kind of design in order for the tests to pass. Here, TDD is promoting the re-use and correction of abstraction techniques.

I've never worked on a project where the design and code match up with each other 100 percent. But the attempt is made to match it as close as possible. Using TDD, the test drives the code, and to some extent, that test code validates the design. This helps greatly to increase the resemblance between the design and the code.

Home / Articles / Deliver Your Code with Confidence Using Test-driven Development / 1 / 2

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.