testdriven.com Wrangling quality out of chaos

A new book on test-driven development has just been published. This 480-page paperback book, published by Morgan Kaufmann, explains the process of TDD in Java, and covers the steps and pitfalls that may be encountered along the way.
Back cover:
Software testing is indispensable and is one of the most discussed topics in software development today. Many companies address this issue by assigning a dedicated software testing phase towards the end of their development cycle. However, quality cannot be tested into a buggy application. Early and continuous unit testing has been shown to be crucial for high quality software and low defect rates. Yet current books on testing ignore the developer’s point of view and give little guidance on how to bring the overwhelming amount of testing theory into practice. Unit Testing in Java represents a practical introduction to unit testing for software developers. It introduces the basic test-first approach and then discusses a large number of special issues and problem cases. The book instructs developers through each step and motivates them to explore further.

Book features
– Shows how tests written before the application is coded can ensure quality and evolutionary design.
– Tackles difficult topics such as persistency, concurrency, distribution, and web applications.
– Includes a discussion of testing with C++ and Smalltalk.

Authors: Johannes Link & Peter Frölich
Published: May 2003
Elsevier International Bookstore
Amazon

About the Author
For 4 years Johannes Link has been project manager and software developer at andrena objects ag in Karlsruhe, Germany. He came to andrena after years of practical software engineering research at the German Cancer Research Center and the German ABB Corporate Research Center. Johannes is responsible for andrena’s internal and external training activities and has published articles on software testing and software development. He holds a diploma degree in medical computer science from Heidelberg University.

Contributor biography
Peter Fröhlich holds a MSc in computer science from the University of Aachen and a Ph.D. in electrical engineering from the University of Hannover. From 1998 to 2002, he worked for ABB Corporate Research as a developer, process improvement consultant, project manager, and manager of a research group. Since 2002 he has worked for Robert Bosch GmbH as a software architect. His research interests include process improvement, conceptual modeling, software architecture, and testing.

For the last fifty years, testing has been viewed as something that gets done toward the end of a project. Sure, there may be integration testing while the project is going on, and testing doesn’t usually start after all the coding is done, but it’s usually in a later phase. However, proponents of XP suggest that this model is completely backwards. As a programmer, you should write tests before you write code, then write just enough code to get the tests to pass. Doing that will help you keep your system as simple as possible.

Author: Roy W. Miller (RoleModel Software, Inc.)
Published: April 22, 2003
PDF version
link

We provide training, mentoring, and coaching services for individual programmers and development teams in transition to eXtreme Programming (XP). Our range of services teach programmers how to vastly improve both the speed and quality of their work. We at Adaption are also available ourselves for business-critical software development projects.

Adaption Software Inc.
1019 Roy Ave.
New Minas, Nova Scotia
Canada B4N 3R7
link

Adaption offers on-site and off-site training courses in TDD. These intensive, hands-on courses are designed to help programmers learn this revolutionary new approach to programming.

In the Basic 3-day course programmers learn the basics quickly but thoroughly. They spend every minute possible working through carefully-designed sample problems. They learn how to use the xUnit family of automated unit test tools, and how to use the refactoring tools built into a contemporary IDE. They learn to write good tests, organize them clearly, work in tiny increments of design/test/code, and spot refactoring opportunities. Afterwards, they should be ready to begin TDD work on pilot projects at their current jobs.

The 5-day course, designed for programmers already familiar with design patterns, refactoring, and the general precepts of XP, is a combination of the Basic and Advanced 3-day courses. It gives students a thorough grounding in TDD and refactoring in a single immersive week.

The Advanced 3-day course is designed for graduates of the basic course. It teaches how to test tricky technologies and resources, using such tools and techniques as Mock Objects and GUI testing frameworks.

Adaption Software, Inc.
1019 Roy Avenue
New Minas, Nova Scotia
Canada
B4N 3R7
link

At Adaption we develop systems that meet and exceed the highest customer expectations, and we offer training, mentoring and coaching services that help your team learn to do the same. Our specialty is Test-driven Development (TDD), a core XP programming practice that is useful independently of XP.

TDD Training

Adaption offers on-site and off-site training courses in TDD. These intensive, hands-on courses are designed to help programmers learn this revolutionary new approach to programming.

Course dates: October 7-8, November 3-7, December 2-4
Location: New Minas, Nova Scotia (Canada)TDD Course Descriptions

3-Day Basic TDD Course (October 7-8 & December 2-4)
In the Basic 3-day course programmers learn the basics quickly but thoroughly. They spend every minute possible working through carefully-designed sample problems. They learn how to use the xUnit family of automated unit test tools, and how to use the refactoring tools built into a contemporary IDE. They learn to write good tests, organize them clearly, work in tiny increments of design/test/code, and spot refactoring opportunities. Afterwards, they should be ready to begin TDD work on pilot projects at their current jobs.

5-Day TDD Course (November 3-7)
The 5-day course, designed for programmers already familiar with design patterns, refactoring, and the general precepts of XP, is a combination of the Basic and Advanced 3-day courses. It gives students a thorough grounding in TDD and refactoring in a single immersive week.

3-Day Advanced TDD Course
The Advanced 3-day course is designed for graduates of the basic course. It teaches how to test tricky technologies and resources, using such tools and techniques as Mock Objects and GUI testing frameworks.

Adaption Software, Inc.
1019 Roy Avenue
New Minas, Nova Scotia
Canada
B4N 3R7

Phone: (902) 681-1640
Fax: (902) 681-1641

General info: info@adaptionsoft.com
Site questions: webmaster@adaptionsoft.com

David Astels, Partner
email: david@adaptionsoft.com
cell: (902) 691-2334

Patrick Wilson-Welsh, Partner
email: patrick@adaptionsoft.com
cell: (902) 679-0286

One thing that makes unit-testing code so hard is the way the real world keeps intruding. If all we had to do was code up tests for methods that sort arrays or generate Fibonacci series, life would be easy. But in the real world we have to test code that uses databases, communications devices, user interfaces, and external applications. We might have to interface to devices that aren’t yet available or simulate network errors that are impossible to generate locally. This all conspires to stop our unit tests from being neat, self-contained (and orthogonal) chunks of code.

Authors: Dave Thomas and Andy Hunt (Pragmatic Programmer)
Published: IEEE Software, May/June 2002
link

Test-driven development is one of the central techniques of Extreme Programming. However, the impact of test-driven development on the business value of a project has not been studied so far. We present an economic model for the return on investment when using test-driven development instead of the conventional development process. Two factors contribute to the return on investment of test-driven development: the productivity difference between test-driven development, and the conventional process and the ability of test-driven development to deliver higher quality code. Furthermore, we can identify when TDD breaks even with conventional development.

Authors: Matthias M. Müller, Frank Padberg (Karlsruhe University, Germany)
Published: International Workshop on Economics-Driven Software Engineering Research (EDSER), Portland, Oregon, USA, May 2003
link

The European Conference on Object-Oriented Programming Conference Committee invites researchers, practitioners, educators, and students interested in object technology to actively participate and contribute to ECOOP 2003. The conference is hosted by the Software Technology Group, Department of Computer Science, Darmstadt University of Technology, supported by the Association Internationale pour les Technologies Objets (AITO).

Dates: July 21-25, 2003
Location: Darmstadt, Germany

http://www.ecoop.tu-darmstadt.de/index.phtml

The Mock Objects project is a generic unit testing framework whose goal is to facilitate developing unit tests in the mock object style. The goal of this project is to provide a core mock objects framework, a methodology for developing and using mock objects, a default set of mock implementation for the standard Java platform APIs, mock implementations for more specialised libraries.
link

The Grinder, a Java load-testing framework freely available under a BSD-style open-source license, makes it easy to orchestrate the activities of a test script in many processes across many machines, using a graphical console application. Test scripts make use of client code embodied in Java plug-ins. Most users of The Grinder do not write plug-ins themselves, instead they use one of the supplied plug-ins. The Grinder comes with a mature plug-in for testing HTTP services, as well as a tool which allows HTTP scripts to be automatically recorded.
link

The main goal of Mock Objects is to unit test a method in isolation of other domain objects. Thus, the Mock Objects approach is to fake domain objects by using simulated copies instead of the real objects. This enables to finely unit test the method with no environment "noise" and to concentrate on unit testing its logic.

Author: The Apache Software Foundation
Published: April 2003
link

Software can never be tested sufficiently, and testing usually starts too late, particularly for J2EE applications. Since components often behave differently when they are alone than when they have been assembled, testing each component individually before two or more components are joined together ensures each piece of code in a J2EE application will work as it was designed to do. Then, if an error occurs in the application, the developer knows the application’s assembly may be the cause. This article presents unit testing techniques and how to apply unit testing to Enterprise JavaBeans (EJBs).

Authors: Michael T. Nygard and Tracie Karsjens
Published: May 2000
link

StrutsTestCase for JUnit is an extension of the standard JUnit TestCase class that provides facilities for testing code based on the Struts framework. StrutsTestCase provides both a Mock Object approach and a Cactus approach to actually run the Struts ActionServlet, allowing you to test your Struts code with or without a running servlet engine. Because StrutsTestCase uses the ActionServlet controller to test your code, you can test not only the implementation of your Action objects, but also your mappings, form beans, and forwards declarations. And because StrutsTestCase already provides validation methods, it’s quick and easy to write unit test cases.

Author: Deryl Seale
link

The proactive method improves testing in two ways. First, traditional approaches tend to assign risk to each test as it’s identified. With nothing to compare to, each test tends to be denoted as high risk. The proactive test-planning structure, however, quickly reveals the available options, so that we can prioritize with respect to all our choices. Second, we can eliminate the common reactive technique of rating the risks of the tests that have been defined. Test-driven development goes a step further.

Authors: Robin F. Goldsmith and Dorothy Graham(SD Magazine)
Published: October 2002
link

This book will transform how you view testing methodologies and procedures. It introduces the reader to essential concepts and approaches used by practitioners in the software testing arena, while also taking into account the realities of low budgets and real schedule deadlines. It is in this context that the specific needs of small, agile project teams are covered in detail.

After walking through the methods most commonly used for testing software, you will know why these very practices are no longer practical for many projects. This books also outlines the steps involved in planning, implementing and evaluating tests of modern, object-oriented software and provides an assessment of currently available methods so that you can choose the right testing procedures for your development project.

Authors: Manfred Rätzmann and Clinton de Young
Published: 2003
Free electronic copy (requires registration)
link

Programmers are often scared that they won’t be able to optimize later. For that reason, they tend to optimize early leading to brittle design. Test driven design can lead to emergent optimization and code that is readily optimizable. If programmers develop test first, many of their upfront concerns about performance can be deferred.

Author: Michael Feathers (Object Mentor, Inc.)
Published: unknown
link

Test first design is fun, but in the beginning, it can be a bit overwhelming. There are all sorts of little fears. You sit at your computer, with that empty screen just staring at you. You pick a test that you want to write, but you stop. “What if I write this test and it passes, and I write another, and another, and then I discover that my objects need to put things on the GUI. How do I write a test for that?” If you are not careful, those sorts of thoughts will derail you for a while. Hopefully, you do hunker down to write the first test and move on, confident that you’ll find a way to write that test when the time comes. This article is about one very interesting strategy you can use when that time comes.

Author: Michael Feathers (Object Mentor, Inc.)
Published: 2001
link

Every time I do a project, it seems we don’t get the hardware until late in the project. This limits the progress the team can make. About all we can do is create speculative design documents, not exactly demonstrable hard evidence of progress. Writing software is hard. Not writing it until late in the development cycle is suicide. A team using Extreme Programming[BECK] will make concrete progress in embedded software development early in the development cycle. Even prior to hardware availability. We can provide regular deliveries of executable software early in the project. We can invest a lot less in written documentation and more in the executable software. Even without the target platform, we will have a rich suite of tests demonstrating our progress.

Author: James Grenning (Object Mentor, Inc.)
Published: March, 2002
link

In order to demonstrate XP (eXtreme Programming) practices, Bob Koss and Bob Martin will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob’s actually did.

Authors: C. Martin and Robert S. Koss (Object Mentor, Inc.)
Published: 2000
link

The paper describes a project developed using many XP practices in a company that has traditional formal process. The paper covers how XP was proposed to the management, how the project seed was started and grown, and some of the issues the team faced during its first six months.

Author: James Grenning (Object Mentor, Inc.)
Published: unknown date
link

Test-first design is one of the mandatory practices of Extreme Programming (XP). It requires that programmers do not write any production code until they have first written a unit test. By definition, this technique results in code that is testable, in contrast to the large volume of existing code that cannot be easily tested. This paper demonstrates by example how test coverage and code quality is improved through the use of test-first design.

Author: Jeff Langr (Object Mentor, Inc.)
Published: March 1, 2002
link

The purpose of this article is to examine how test first programming produces code which adheres to certain design principles. In particular we will see that test first programming insures that we follow the Open/Closed, Liskov Substitution Principle and Dependency Inversion principles, introduced to us in 1996 by Robert C. Martin. Here we will revisit the Copy program, which Robert used to demonstrate the Dependency Inversion Principle, only we will do so test first using Kent Beck and Erich Gamma’s JUnit, a testing framework for Java.

Author: Erik Meade (Object Mentor, Inc.)
Published: February 13, 2002
link

Although developers have been unit testing their code for years, it was typically performed after the code was designed and written. As a great number of developers can attest, writing tests after the fact is difficult to do and often gets omitted when time runs out. Test-driven development (TDD) attempts to resolve this problem and produce higher quality, well-tested code by putting the cart before the horse and writing the tests before we write the code. One of the core practices of Extreme Programming (XP), TDD is acquiring a strong following in the Java community, but very little has been written about doing it in .NET.

Author: Peter Provost (site)
Published: March 12, 2003
link

ThoughtWorks’ new Open Source site makes available many useful projects.

http://opensource.thoughtworks.com/index.html

Dave Astel’s column on Borland Developer Network explores the world of Test-driven Development.

http://bdn.borland.com/coadletter/testdrivendevelopment/