extreme programming

People are creatures of habit, particularly programmers: We seek consistency, whether it is the tried-and-true waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee. Companies or projects looking to adopt an agile process neglect the fundamental concern of an individual developer: "What will my day to day look like working in an agile environment?"

One of the things testers often notice about Extreme Programming (XP) is that there is no defined role for testers on the team. Yet XP teams describe themselves as "test infected." They practice Test-Driven Development (TDD), writing executable unit tests before writing the code to be tested. Many teams practice Acceptance Test-Driven Development (ATDD), writing executable acceptance tests before implementing a feature. They use continuous integration to give them rapid feedback about the effects of changes. They practice pair programming, a technique that results in all code being peer reviewed before it's checked in. In short, XP teams test continuously from the very first moment of any given project. You could even call them "test obsessed." That obsession helps explain why Elisabeth Hendrickson, author of Test Obsessed, likes XP teams so much.

One of the things testers often notice about Extreme Programming (XP) is that there is no defined role for testers on the team. Yet XP teams describe themselves as “test infected.” They practice Test-Driven Development (TDD), writing executable unit tests before writing the code...

In this article, the authors the use of basic patterns that can help build a software configuration management process that works well with your agile development environment. They discuss how codeline policy, private work spaces, smoke tests, private system builds, integration building, unit testing, and regression testing all work together to enable you to maintain an active development line.