program selection system

In this clinic session, attendees will pair-program on implementing small software application features following the TDD Ping Pong game rules. Each game will last for a few minutes, and the programmer with the least time driving (i.e. doing the simplest thing that works and coming up with the most tests) will be declared winner. This game is a great opportunity to sharpen your TDD, refactoring, and pair programming skills Winners will receive prizes, so get ready for Andy and Dave’s challenge!

Intent
To help the participants learn, how to build acceptance criteria and automated acceptance tests from User Stories to drive development and testing.

Overview

Main Message:

Continuous Integration has put a lot of focus on automation of the build and unit test process. This quest for automation has been expanding to include more and more automated tests and deployments as well. This presentation provides an overview of how to apply automation to activities further within the life-cycle.

Description:

The second great myth of software development training is the notion that most programming most of the time is on new code. In fact, most developers spend most of their time working on CRRAP: Code Requiring Remedial Attention Promptly. In this course, we’ll lay out the five basic patterns for bringing complex legacy code under perfectly tested control. If you’ve ever heard or said “Don’t touch that, you don’t know what it’s connected to,” this class is for you. Each pattern is illustrated with a complete real-world

Continuous Integration is at the heart of every Agile project. However, the status of the build process is only one source of information about the health of a project. Project velocity, bug counts, system performance, code metrics, and production uptime all provide valuable information about project health. But these bits of information are generally locked away in different systems and are not easily accessed or leveraged by the software team. Continuous monitoring is about pulling all of these sources of information together in a way that is visible and empowering for the entire team.

The instructors wish, when they were first learning test-driving, refactoring, and deep OO, that they had had a genuine side-by-side comparison between code Heaven and code Hell. Such an object lesson would have made the value and benefits of agile programming practices so much more plain, so much sooner. Alas for us, but hurray for you! In this clinic session you will be able to compare and work with two very different implementations of the same problem domain: one of them fabulously ugly, and the other of them — well — much closer to gorgeous.

Tale of Two Codebases

Test Driven Development is a key Agile Practice. With TDD, programmers get instant feedback that their code does what they intend. This class shows the motivations behind TDD, but does not stop there. Attendees get first hand experience at TDD, writing well tested code. You will see how tests can prevent many bugs and memory leaks. We’ll use CppUTest, an open source test harness, to collect, organize and automate C++ unit tests.

Summary

There are two questions worth asking oneself over and over when creating automated acceptance tests.

• What is the purpose of this test?
• Does the test express this purpose as clearly as possible?

This clinic uses exercises and examples to reinforce the good habit of writing tests with a clear purpose. Our focus is on favoring “declarative-style” tests over “procedural-style” tests. (See Bill Wake’s explanation of the difference at http://xp123.com/xplor/xp0503/index.shtml)

It has been over six years since the first release of NUnit 2.0. In that time there have been literally millions of tests that have been authored. Many of these tests have become invaluable resources for their teams. Unfortunately there have been others that have not been maintained and were viewed as a waste of effort. What separates tests that are maintained from tests that are discarded?

In this session of the TDD clinic, Ron and Chet will walk you through test-driven-development in Java. Participants will write a small program using a very short development cycle of design-test-code-release repeat.