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!

The phrase clean code encapsulates a philosophy of coding and specific principles that improve code quality and extensibility. These principles include the importance of code that clearly expresses its intent and the effective use of encapsulation and abstractions to isolate details appropriately. What about at the architecture level? Can systems be clean?

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:

Often it is suggested that Test Driven Development has moved into the mainstream and that not applying a test first approach is exceptional. Having worked with TDD for the last five years I have observed that far from being ubiquitous, effective application of TDD is uncommon. This session takes a pragmatic approach in evaluating the implementation of, impediments against and measurable benefits of TDD on a commercially successful project. Analysis of this experience will show how and why TDD is being used incorrectly and how this situation can be corrected.

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.

Abstract

Developer practices for traditional and agile Java development are well understood and documented. But dynamic languages—Groovy, Ruby, and others—change the ground rules. Many of the common practices, refactoring techniques, and design patterns we have been taught either no longer apply or should be applied differently and some new techniques also come into play. In this talk, techniques for agile development with dynamic languages are discussed. How should we apply design patterns? How should we better apply refactoring techniques? What new aspects do we need to think about?

First, I’d like to present an experience report about real-life development with mock objects: the test-driven struggle. Then I will show how to improve the TDD experience and code quality through a slightly different approach to mocking: taking a step back from the invasive nature of interaction based testing and getting closer to the way we do state based testing. Finally, I will introduce a new mock library for java: Mockito which was driven by these observations. Mockito implements what Gerard Meszaros calls a Test Spy.

Process in short:

Experience report (shows the problem) -> tutorial of a new tool (tries to fix the problem)

Printed Program Guide Blurb
Books on Test-Driven Development abound for C# and Java, but there are few directed towards C++ programmers. Yet much software is written is C++, and C++ is an extremely powerful language, one that I’ve found to be quite well-suited for doing TDD. I will present a series of practical and efficient testing patterns specifically for C++. Most of the techniques involve templates; one of them involves lexical closure. Many of these techniques are also well-suited for dealing with legacy code.