As with Pragmatic Unit Testing in C#, this is a beautiful book on how to go about using unit testing. Good clear explainations on when to test, what to test, and how to go about testing it. Another fine introductory text, that has a lot to offer to those who already unit test and want a bit of theory to go with it.

---

Product Description

Learn how to improve your Java coding skills using unit testing. Despite it's name, unit testing is really a coding technique, not a testing technique. Unit testing is done by programmers, for programmers. It's primarily for our benefit: we get improved confidence in our code, better ability to make deadlines, less time spent in the debugger, and less time beating on the code to make it work correctly. This book shows how to write tests, but more importantly, it goes where other books fear to tread and gives you concrete advice and examples of what to test--the common things that go wrong in all of our programs. Discover the tricky hiding places where bugs breed, and how to catch them using the freely available JUnit framework. It's easy to learn how to think of all the things in your code that are likely to break. We'll show you how with helpful mnemonics, summarized in a handy tip sheet (also available from our www.pragmaticprogrammer.com website) to help you remember all this stuff. With this book you will:

• Write better code, and take less time to write it
• Discover the tricky places where bugs breed
• Learn how to think of all the things that could go wrong
• Test individual pieces of code without having to include the whole project
• Test effectively with the whole team

We'll also cover how to use Mock Objects for testing, how to write high quality test code, and how to use unit testing to improve your design skills. We'll show you frequent "gotchas"--along with the fixes--to save you time when problems come up. We'll show you how with helpful mnemonics, summarized in a handy tip sheet (also available from our www.pragmaticprogrammer.com website). But the best part is that you don't need a sweeping mandate to change your whole team or your whole company. You don't need to adopt Extreme Programming or Test-Driven Development, or change your development process in order to reap the proven benefits of unit testing. You can start unit testing, the pragmatic way, right away.

---

Product Details

• Amazon Sales Rank: #167466 in Books
• Published on: 2003-09-01
• Original language: English
• Number of items: 1
• Binding: Paperback
• 176 pages

From the Publisher
Improve your Java coding skills using unit testing: it's really all about coding, not testing. This book shows not just how to test, but what to test. Discover the tricky hiding places where bugs breed, and how to catch them using JUnit. You don't need to adopt Extreme Programming, or Test-Driven Development in order to reap the proven benefits of unit testing, the pragmatic way. Volume II of the Pragmatic Starter Kit.

About the Author
Andy Hunt and Dave Thomas have more than 50 years combined experience, developing software for clients around the world. For the last 10 years they've been working together as The Pragmatic Programmers, helping clients write software and improve their development processes. They are authors of the best-selling The Pragmatic Programmer, and have written several other books. They speak at conferences globally, and are editors of IEEE Software's "Construction" column.

Excerpted from Pragmatic Unit Testing In Java with JUnit by Andy Hunt, Dave Thomas. Copyright © 2003. Reprinted by permission. All rights reserved.
Chapter 6 Using Mock Objects

The objective of unit testing is to exercise just one method at a time, but what happens when that method depends on other things—hard-to-control things such as the network, or a database, or even a servlet engine?

What if your code depends on other parts of the system — maybe even many other parts of the system? If you’re not careful, you might find yourself writing tests that end up initialising nearly every system component just to give the tests enough context in which to run. Not only is this time consuming, it also introduces a ridiculous amount of coupling into the testing process: someone goes and changes an interface or a database table, and suddenly the setup code for your poor little unit test dies mysteriously. Even the best-intentioned developers will become discouraged after this happens a few times, and eventually may abandon all testing. But there are techniques we can use to help.

In movie and television production, crews will often use standins or doubles for the real actors. In particular, while the crews are setting up the lights and camera angles, they’ll use lighting doubles: inexpensive, unimportant people who are about the same height and complexion as the expensive, important actors lounging safely in their luxurious trailers.

The crew then tests their setup with the lighting doubles, measuring the distance from the camera to the stand-in’s nose, adjusting the lighting until there are no unwanted shadows, and so on, while the obedient stand-in just stands there and doesn’t whine or complain about "lacking motivation" for their character in this scene.

So what we’re going to do in unit testing is similar to the use of lighting doubles in the movies: we’ll use a cheap stand-in that is kind of close to the real thing, at least superficially, but that will be easier to work with for our purposes.

6.1 Simple Stubs

What we need to do is to stub out all those uncooperative parts of the rest of the real world and replace each of them with a more complicit ally—our own version of a "lighting double." For instance, perhaps we don’t want to test against the real database, or with the real, current, wall-clock time. Let’s look at a simple example.

Suppose throughout your code you call your own getTime() method to return the current time. It might be defined to look something like this:

public long getTime() {
return System.currentTimeMillis();
}

(In general, we usually suggest wrapping calls to facilities outside the scope of the application to better encapsulate them — and this is a good example.) Since the concept of current time is wrapped in a method of your own writing, you can easily change it to make debugging a little easier:

public long getTime() {
if (debug) {
return debug_cur_time;
} else {
return System.currentTimeMillis();
}
}

You might then have other debug routines to manipulate the system’s idea of "current time" to cause events to happen that you’d have to wait around for otherwise.

This is one way of stubbing out the real functionality, but it’s messy. First of all, it only works if the code consistently calls your own getTime() and does not call the Java methodSystem.currentTimeMillis() directly. What we need is a slightly cleaner—and more object-oriented—way to accomplish the same thing.

6.2 Mock Objects

Fortunately, there’s a testing pattern that can help: mock objects. A mock object is simply a debug replacement for a realworld object. There are a number of situations that come up where mock objects can help us. Tim Mackinnon [MFC01] offers the following list:

• The real object has nondeterministic behavior (it produces unpredictable results, like a stock-market quote feed.)
• The real object is difficult to set up.
• The real object has behavior that is hard to trigger (for example, a network error).
• The real object is slow.
• The real object has (or is) a user interface.
• The test needs to ask the real object about how it was used (for example, a test might need to confirm that a callback function was actually called).
• The real object does not yet exist (a common problem when interfacing with other teams or new hardware systems).

Using mock objects, we can get around all of these problems. The three key steps to using mock objects for testing are:

1. Use an interface to describe the object
2. Implement the interface for production code
3. Implement the interface in a mock object for testing

---

Customer Reviews

Good introduction...
but then it doesn't offer much beyond what you can glean from reading about the subject on the internet. It also misses out a great deal of stuff which would be useful such as how to test private methods of classes, using databases in testing using DbUnit or how to use Cactus or many of the other frameworks it mentions. It does cover a lot of ground on what to test and why you are testing, but I found it very brief and lacking information on how to test.