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.
"If you want to improve the quality of the software, stop the problem at the source. Begin by looking at the requirements: most bugs are caused by a lack of agreement on the requirements, not by simple developer mistakes."
In this set of slides taken from the 2001 International Conference On Software Management & Applications of Software Measurement, a clear example outlines the necessity for getting the requirements right and conducting unit tests all along the development process.
Author: Elisabeth Hendrickson (QualityTree)
Published: February 14, 2001
link
This paper examines the challenges of testing enterprise integration solutions and proposed a testing approach to tackle inherent complexities. This approach is accompanied by a framework that makes integration testing more effective and efficient. Additionally, the paper discusses the implications of Web services and service-oriented architectures on the proposed testing framework, and provides guidelines for the design of new integration solutions to improve testability.
Authors: Gregor Hohpe, Wendy Istvanick (ThoughtWorks)
Published: November, 2002
link
In this step-by-step series, the hero, a TDD beginner, learns to understand, by trial and error, what it means to practice test-first and refactorings. An easy and clear introduction to good programming practice through test-driven development.
Author: Robert C. Martin
Published: 13 February – 15 october 2002
These chapters are derived from Principles, Patterns, and Practices of Agile Software Development.
link
In our research, we ran a set of structured experiments with 24 professional pair programmers. One group developed code using TDD while the other a waterfall-like approach. Both groups developed a small Java program. We found that the TDD developers produced higher quality code, which passed 18% more functional black box test cases. However, TDD developer pairs took 16% more time for development. A moderate correlation between time spent and the resulting quality was established upon analysis.
Authors: Boby George & Laurie Williams (NCSU)
Published: March 2002
link
This viewlet shows the implementation of Kent Beck’s example from Contributing to Eclipse, in a clear, animated presentation.
Author: Carlos E. Perez (blog)
Published: February 2003
Format: Flash presentation
See also:
Yahoo Groups: contributing to Eclipse
Eclipse (Universal Tool Platform)
link
Very roughly speaking, you usually have two choices when it comes to methodology. You can either use a "heavy" methodology with lots of design documents and procedures, or you can hack, doing whatever comes naturally along the path of least resistance. If you choose to hack, you can get a lot of features done quickly in the beginning, but as your application grows in complexity, you will be slowed down by hard-to-find bugs and the need to maintain duplicated code.
Agile methodologies such as XP attempt to solve this problem by doing less up-front design and making sure it is always possible to make design changes, and by constantly improving the structure of the code using a set of systematic procedures known as refactoring.
In XP, automatic testing of the produced software takes a central role in the development process. For unit tests, there are a multitude of freely available testing frameworks for many programming languages while there seems to be a complete lack of available testing frameworks for automating acceptance tests. At the department of Computer Science, Lund University, we felt the need for a light-weight acceptance testing framework that could be used in both students programming projects courses and in our own research projects.
This paper discusses the thoughts behind, and the implementation of, JaTack, a very lightweight framework for automating acceptance tests for batch-oriented programs.
Anders Nilsson
LUCAS – Center for Applied Software Research
August 2002
link
Refactoring is about saying, "Let’s restructure this system in order to make it easier to change it." The corollary is that it’s pointless to refactor a system you will never change, because you’ll never get a payback. But if you will be changing the system—either to fix bugs or add features—keeping the system well factored or making it better factored will give you a payback as you make those changes.
Bill Venners
artima.com
November 4, 2002
link
An important part of any software development process is getting reliable builds of the software. Despite it’s importance, we are often surprised when this isn’t done. Here we discuss the process that Matt has put into place on a major project at ThoughtWorks, a process that is increasingly used throughout the company. It stresses a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily thus reducing integration problems.
Martin Fowler & Matthew Foemmel
www.martinfowler.com
January 1, 2001
link
The abysmal quality of software has led to Extreme Programming (XP), a discipline for developing software that requires test-driven design, continuous testing and acceptance of constant change. As one application services provider (ASP) delivering complex demand chain management solutions has found, XP has enabled rapid development of quality software. The XP movement, which Kent Beck kicked off with a paper on Smalltalk programming, emphasizes testing that helps to bring new developers up to speed rapidly. It also aids developers when they refactor, or change, code. Every programmer writing code has to refactor existing code to streamline it, and continuous testing gives developers confidence that their refactoring works.
Richard Adhikari
edwardh.com
January 1, 2002
link
The key to working effectively with legacy code is getting it to a place where it is possible to know that you are making changes one at a time. When you can do that, you can nibble away at uncertainty incrementally. The tests that you use to do this are a bit different from traditional tests. I like to call them test coverings.
Michael Feathers
Object Mentor, Inc.
April 9, 2002
link
Acceptance tests must go beyond functionality to determine whether the packages meet goals such as specified performance levels. Automating end-to-end testing from the customer point of view can seem as daunting as driving along the edge of a cliff with no guard rail. At Tensegrent, a software engineering firm in Denver organized around XP practices, the developers and the tester have worked together to design modularized, self-verifying tests that can be quickly developed and easily maintained. This is accomplished through a combination of in-house and vendor-supplied tools.
Lisa Crispin, Tip House & Carol Wade
Agile Alliance
May 1, 2001
link
Artima SuiteRunner, a free, open source unit and conformance testing toolkit for Java, was released in late January. Find out why the authors felt the need to create Artima SuiteRunner and learn how you can use it to run JUnit test suites.
Bill Venners, Matt Gerrans and Frank Sommers
artima.com
January 27, 2003
link
The great thing about software patterns is that they convey many useful design ideas. It follows, therefore, that if you learn a bunch of these patterns, you’ll be a pretty good software designer, right? I considered myself just that once I’d learned and used dozens of patterns. They helped me develop flexible frameworks and build robust and extensible software systems. After a couple of years, however, I discovered that my knowledge of patterns and the way I used them frequently led me to over-engineer my work.
Joshua Kerievsky
Industrial Logic
April 2002
link