A series of chapters patterned after Jeff Langr’s book, Agile Java: Crafting Code with Test-Driven Development:
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
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.
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.
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)
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.
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.
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.
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