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

Failures Are the Pillars of Success

• 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

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

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

testWithdrawMoney() and
testDepositMoney()

transactMoney(Boolean transactionType, double acctBalance, double amt) 

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.

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.

Elsewhere on internet.com:

WebDeveloper Java
Lots of Java information on webdeveloper.com

WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.

ScriptSearch Java
Hundreds of free Java code files to download.

jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.