program selection system

Automated unit testing is the agile software development equivalent of “in-process inspection” in Lean Production systems. xUnit is the generic name given to the family of tools/frameworks used by developers when developing automated unit tests. The community has now had enough experience with using XUnit to start cataloging “best practices” and “not so best practices” as patterns and smells. This tutorial introduces a number of these “test smells”, describes their root causes, and suggests possible solutions expressed in the form of patterns.

90 Word Abstract :

It’s easy to speak of test-driven development as if it were a single method, but there are several ways to approach it. In our experience, different approaches lead to quite different solutions.

In this workshop, we’re not trying to decide which approach is best. Rather, we’ll use concrete examples to explore

• What goes into the moment of decision when a test is written?
• How do you think about the problem you’re trying to solve?
• What strategies or techniques help you write the first few tests?

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!

Narrative Testing leverages script-based testing tools and DSTLs to express Story Tests in the user’s own language. Developers and customers cooperate to create customer-readable scripts based on User Stories, which are executed interactively against the application UI. Through Narrative Testing, customers are able to view the executing test, and to experientially tie steps in the test to changes in the application state, increasing customer confidence in testing.

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

This experience report outlines technical lessons learned over a several year period across several projects within an organisation which aggressively applied most of the agile practices with much success. The success, however, was not been achieved without challenges and lessons learned along the way. This paper outlines the interesting observations we made while trying to turn the agile dials to eleven. Our starting assumption when we began this journey several years ago was that productivity and quality were opposing forces; you had to trade one off against the other. However, after turning the dials to eleven, we now believe that you can much more of both than we previously thought possible. In fact, we believe that applying the practices outlined in this experience report allow both much higher quality and higher productivity than traditional development.

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.

Depuis longtemps fascinés par l’expressivité et l’élégance de ces langages, nous cherchons à comprendre comment articuler les pratiques XP - TDD, Binômage, remaniement du code, itérations - et le paradigme fonctionnel; à identifier les points faibles et forts de ces langages par rapport au paradigme dominant - l’objet - dans le cadre de processus de développement agiles; à convaincre le plus grand nombre, enfin, de la pertinence de modifier nos modes de pensée dans le sens où ces langages nous y invitent.