Integration tests are a scam, a self-replicating virus that takes over your project and burdens you with long-running, fragile, hard-to-understand test suites. You’re probably writing 2-5% of the integration tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integration tests probably duplicate each other all over the place. When an integration test fails, who knows what’s broken? When you refactor, you have to fix dozens of integration tests. Stop it. Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.

You’ve started your new project and “surprise” (not really) you’re dealing with legacy code. This unique workshop will focus on a few specific techniques that help make up the majority of what to do in improving legacy code design. Our forefathers gave us “Extract Method” and “Rename”. Cleaning up code is fun and challenging at times!

XUnit is the generic name given to the family of tools/frameworks used by developers when developing automated unit tests. JUnit, NUnit, MsTest and CppUnit are some of the better known members of the family. High quality automated unit tests are one of the key development practices that enable incremental development and delivery of software. This tutorial provides the participants with a vocabulary of smells and patterns with which to reason about the quality of their test code and a set of reusable test code design patterns that can be used to eliminate the smells.

This talk discusses techniques that can be used to apply Agile practices to atypical technologies, and presents case studies on how to apply Agile practices to projects built with technologies including Teradata (Database), and MicroStrategy (BI).

The instructors wish, when they were first learning test-driving, refactoring, and OO, that they had had a 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 workshop 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 — a lot better. This is a close-repeat of a successful session we gave at Agile 08.

Coding Dojos are sessions were participants are invited to participate in a programming challenge. They get the opportunity to practice Extreme Programming techniques such as Test-Driven Development, Simple Design and Pair Programming. In this dojo, the audience will be asked to concentrate on adding features (while preserving existing functionalities) to a Java project that has not been written with testability in mind. In other words, we will work on legacy code. The Randori format will be used to let as many participants as possible do actual coding.