Test Driven Development An approach to writing better code Jimmy Zimmerman Intel Corporation

Outline What is TDD? Why perform TDD? Myths about TDD How do we do TDD? When NOT to perform TDD Tools for TDD Example of TDD Q&A

The Problem Over 50% of all software projects are initiated and then canceled. Over 80% of software projects completed suffer massive * cost and time overruns. Quality, or the lack thereof, is a major issue. Code is bloated, buggy, and marginally useful. * Over 100% of budget and/or time. West, pg 87

The Solution (Isn’t) building / using new tools. creating more elaborate documents. adding more layers of process “better” programming languages

The Solution (is) producing “better people” aka Better Programmers, regardless of method or intended use of the application.

FACT 1 The most important factor in software work is not the tools and processes used by the programmers but rather the quality of the programmers themselves.

I. What is TDD? Definition: Test Driven Development is the practice of utilizing tests to document and define the behavior of software. Tests DRIVE the design of software, not follow already designed software. Design documentation is finalized from the tests, not used to create the tests from.

FACT 2 The most important part of writing programs is creating the tests that describe the behavior of the software and not the software itself.

II. Why perform TDD? Eliminates Duplication of Code Shared Responsibility Common Language Simplest Solution Possible Modularization A “Gateway Habit”

Eliminates Duplication of Code Code duplication epitomizes bad software. Tests describe the behavior of the code we are writing. When writing the code, we will find common behavior and refactor. Tests provide the ability to reliably refactor existing code. Tests ensure the behavior of the code does not change after refactoring.

Shared Responsibility Application code is the responsibility of all programmers on a project. Code that is unfamiliar to a programmer is hard to learn. Tests document the behavior of code, making it easier to learn. A test allows the code to be modified by any developer. This prevents “pigeon-holing” and overall increases speed of development. The more peer review of code by the greatest number of programmers the better.

Common Language Programs are written in code. The code has a language. Developers understand the language. Code is deterministic. The tests are written with the common language of the application. A single language documents the behavior of the application and the implementation of the behavior. Translations of any kind introduce errors and misunderstandings to the meaning.

Simplest Solution Possible Software is complex. The simpler the code the more resilient and easier it is to change. Tests define requirements. Writing code should satisfy the requirements no less and no more. Every line of code requires maintenance. Adding more code adds to the maintenance by adding complexity. Program for today. Worry about tomorrow when it comes. “Simplest Solution that Works is NOT the first stupid idea that pops into your head” – Udi Dahan

Program for Today (expanded) Q: Why? Isn’t it better to plan for tomorrow? A: No –Planning is not implementing. –Tomorrow might not come. –When you finally need it, you probably will know more about how to do it correctly. –Tests mitigate the cost of change over time.

Cost of Change

FACT 3 Adding features when they are needed saves more money over time than it costs to build before they are needed.

Modularization Good software depends on building small single use modules. While the technology of modules changes (methods, messages, global functions, APIs) each provides a quantifiable set of behaviors. Once you start to TDD, you will find that your code will naturally become more modular to support the ease of testing.

A “Gateway Habit” TDD is the foundation that enables other habits of successful development processes. –Frequent, incremental releases (less is more) –Peer review –Early customer feedback –KISS –Refactoring –Agile methods

III. Myths about TDD 1.It’s just for OOP 2.It’s a replacement for good programming skill 3.It’s hard to do 4.I don’t have time 5.Testing is for QA

Myth 1: It’s just for OOP NO. –TDD is about a mindset and not a technology. –While objects make it easier to program complex applications, all programs benefit from writing tests. They act as an outline for what you want to do. –Tests can work with any language and platform. ( I’ve seen TDD done in x86 assembler at school! )

Myth 2: It’s a replacement for good programming skill NO. –No matter how good you are, you will make a mistake eventually. –Even if you never make mistakes someone else will need to maintain your code. It is unlikely they can know all the behaviors your code has. –This is the most important of all programmer skills and not a replacement for skill!

Myth 3: It’s hard to do INCORRECT. –It makes your job easier by breaking down your work into manageable steps. –It allows you to make changes to existing code easily. –It does take discipline however. ( so yes in that it’s “hard” to not be lazy )

Myth 4: I don’t have time WRONG. –Tests prevent bugs. Less bugs make for more time over the life of the application. –An ounce of prevention is worth a pound of cure. –They allow someone else to help you without making your life harder.

Myth 5: Testing is for QA WRONG. –QA is not there to find bugs. They are there to confirm the behavior of application meets the agreed functionality. –A developer is responsible for writing secure, bug free, and reliable code that provides the exact functionality the program specifies. –A bug should be an exceptionally rare occurrence in QA. Tests are the tool to make them rare.

IV. How do we do TDD? 1.Write the test code. 2.Compile the test code (this should fail) 3.Implement just enough to compile. 4.Run and watch it fail 5.Implement just enough to make the first test pass. 6.Run the test and watch it pass. 7.Refactor for clarity and to eliminate duplication. 8.Repeat from top.

Fact 4 Red -> Green -> Refactor Small verifiable steps are better. They provide immediate feedback that builds confidence in code. When something goes wrong, you will immediately know where and why.

V. When NOT to perform TDD TDD requires an upfront investment in resources. Over the course of a project development cycle this amount of effort is a very small percentage of the overall work. The end of the cycle does not allow the cost to be minimized and therefore it is inappropriate to begin TDD during that phase.

Tools for TDD Tools do not make or break TDD, they only aid it ( remember it’s a mindset ). Tools depend on platform. –nUnit –mbUnit –jUnit –Page tracing –ACT –Invent a tool!

Example of TDD Interactive Example using Visual Studio.Net 2003 and nUnit. Creating an unbounded stack Push/Pop/IsEmpty capability Properly limits bound access

Task 1

Task 2

Task 3