testdriven.com Wrangling quality out of chaos

A series of chapters patterned after Jeff Langr’s book, Agile Java: Crafting Code with Test-Driven Development:

The basics – Getting started – Testing equality – Testing hash code – Shuffling and dealing – Handling exceptions – Refactoring tests – Adding some bulk

Author: Jeff Langr
Published: InformIT, 2005-2006
Other links to articles by Jeff Langr: InformIT – [url=http://www.testdriven.com/search.php?query=langr&action=results]testdriven.com[/url]
link

This book’s excerpt from Agile Development With Iconix Process provides an introduction to a process mixing the UML use case approach and Test-Driven Development.

Authors: Doug Rosenberg, Matt Stephens & Mark Collins-Cope
Published: Methods and Tools, Spring 2005
link

J2SE 5.0 introduced a new facility known as annotations. Annotations are a metaprogramming facility that allow you to mark code with arbitrarily defined tags. The tags (generally) have no meaning to the Java compiler or runtime itself. Instead, other tools can interpret these tags. Examples of tools for which annotations might be useful include IDEs, testing tools, profiling tools, and code-generation tools.

In this lesson you will begin to build a testing tool, similar to JUnit, based upon Java’s annotation capabilities. The testing tool, like JUnit, will need to allow developers to specify assertions. Instead of coding assertion methods, you will learn to use Java’s built-in assertion capability.

Author: Jeff Langr
Excerpted from Agile Java: Crafting Code with Test-Driven Development
link

Refactoring software by hand can be a real pain. So why not just automate the process? In this chapter, Joshua Kerievsky explains the whys and hows of refactoring, and why you shouldn’t trust that automated refactoring program.

Author: Joshua Kerievsky
Published: InformIT, January 28, 2005
Excerpted from Refactoring to Patterns
link

Have you ever had to work on a piece of code and found that it was hard to understand? Maybe the logic was convoluted, the identifiers meaningless, or worse, misleading. You say there was documentation? Was it readable? Did it make sense? Was it up to date with the code? Are you sure? How do you know? This chapter discusses programming by intention, a central idea in XP. It means making your intent clear when you write code.

Author: Dave Astels
Published: February 4, 2005, courtesy of Prentice Hall PTR
Excerpted from Test-Driven Development: A Practical Guide
link

This chapter is a simple but realistic case study of using Open Source tools in everyday development. In particular, this chapter uses ASpell, a commercial-caliber spell checking component that supports twenty-some different language dictionaries, as an example.

Author: Brian Nantz
Published: Jan 7, 2005
(Sample chapter extracted from Open Source .NET Development: Programming with NAnt, NUnit, NDoc, and More)
link

Maven started life as a subproject of Turbine, a Web application framework. It was born out of the need of its lead developer, Jason Van Zyl, to easily add in new pieces of functionality to his build process, such as unit testing or source metrics, both of which can be extremely important to a large project. The first iterations used Ant as the build system, but then Maven moved away from Ant to use Jelly as its primary scripting engine to build the plug-in architecture that is there today.

This book chapter is excerpted from: Professional Java Tools for Extreme Programming (Chapter 26).
link

The old adage, "If it ain’t broke, don’t fix it," doesn’t necessarily apply in the case of technology. Projects continually require alterations, updates, and enhancements. This chapter outlines the nature of code change, and suggests some of the challenges to be faced when making these changes.

Author: Michael Feathers
Published: InformIT, January 14, 2005
Excerpted from Working Effectively with Legacy Code
link

You can think of these smells as being caught by a software metric. Each metric tends to catch different aspects of why code isn’t as good as it could be. Some metrics measure variants of code length; others try to measure the connections between methods or objects; others measure a distance from an ideal.

Smells Covered: Comments, Long Method, Large Class, Long Parameter List.

Author: William C. Wake
Published: Addison Wesley Professional, January 9, 2004
Link to Amazon
link

As software engineers, we often deal with performance requirements and end-user acceptance requirements. Why should the development process be any different? Quite frankly, it shouldn’t. Development projects should have realistic requirements for how long a build and test cycle should take. Metrics should be collected on a regular basis, so corrective action can be taken as soon as the build and test times exceed requirements.

Excerpted from Test-Driven Development: A J2EE Example, this chapter helps you select the right tools for getting started with test-driven development (TDD).

Author: Thomas Hammell, with Russell Gold and Tom Snyder
Published: JavaWorld, December 6, 2004
link