© 2001-2004 Craig Murphy Craig Murphy [email protected] An Introduction to Test-Driven Development (TDD)

© 2001-2004 Craig Murphy

Craig [email protected]

http://www.CraigMurphy.com

An Introduction to Test-Driven Development

(TDD)

An Introduction to Test-Driven Development (TDD)An Introduction to Test-Driven Development (TDD) 2

Disclaimer

Developer = Programmer

We’re talking about unit testing – i.e. testing the internals of a class

Black box testing for objects Classes are testing in isolation

Loosely coupled, highly cohesive architectures


Agenda

Motivation What is TDD? TDD Stages TDD in Delphi Demonstration

Delphi C#Builder using csUnit

Why TDD?

Summary Notable Quotes


Motivation

One of my goals for Q3/Q4 2003 was to become evangelical about eXtreme Programming (XP) and Test-Driven Development (TDD)

TDD sits nicely in the XP “way of doing things” TDD can be used without practicing XP

Writing articles and giving presentations is one such way of achieving that goal

To reduce the amount of re-testing that is required Especially with legacy applications To avoid introducing new bugs after refactoring existing

code


What is TDD?

“Before you write code, think about what it will do. Write a test that will use the methods you haven’t

even written yet.”

Extreme Programming Applied: Playing To Win Ken Auer, Roy Miller “The Purple Book”

A test is not something you “do”, it is something you “write” and run once, twice, three times, etc. It is a piece of code Testing is therefore “automated” Repeatedly executed, even after small changes


What is TDD?

TDD is a technique whereby you write your test cases before you write any implementation code

Tests drive or dictate the code that is developed

An indication of “intent” Tests provide a specification of “what” a piece of

code actually does Some might argue that “tests are part of the

documentation”


Agenda



Why TDD?



TDD Stages

1. In Extreme Programming Explored (The Green Book), Bill Wake describes the test / code cycle:

2. Write a single test3. Compile it. It shouldn’t compile because you’ve not written

the implementation code4. Implement just enough code to get the test to compile5. Run the test and see it fail6. Implement just enough code to get the test to pass7. Run the test and see it pass8. Refactor for clarity and “once and only once”9. Repeat


TDD Stages

Write a test

Compile

Fix compile errors

Run test,watch it fail

Write code

Run test, watch it pass

Refactor code(and test)


Agenda



Why TDD?



TDD in Delphi

DUnit An xUnit implementation for Delphi

xUnit is a colloquial umbrella term Platform-specific implementations

e.g. sUnit, JUnit, XMLUnit

Provides classes with methods to help us write test cases

TTestCase “Check” functions…


TDD in Delphi using DUnit

TObject

TYourClass

TTestCase

TTestYourClass

SomeMethod1

SomeMethod2

TestSomeMethod1

TestSomeMethod2

TestSomeMethod1

and SomeMethod2


TDD in Delphi using DUnit

CheckCheck (condition: boolean; msg: string = ''); (condition: boolean; msg: string = '');

CheckEquals (expected, actual: integer; msg: string = ''); CheckEquals (expected, actual: integer; msg: string = '');

procedure TTestCaseList.TestAdd;procedure TTestCaseList.TestAdd;var AddObject: TObject;var AddObject: TObject; FEmpty : TList;FEmpty : TList;BeginBegin FEmpty := TList.Create;FEmpty := TList.Create; AddObject := TObject.Create;AddObject := TObject.Create;

FEmpty.Add(AddObject);FEmpty.Add(AddObject);

// The following calls check to see if everything went OK.// The following calls check to see if everything went OK. // When check fails, it will end up in the TestResult as a failure.// When check fails, it will end up in the TestResult as a failure. Check(FEmpty.Count = 1);Check(FEmpty.Count = 1); Check(FEmpty.Items[0] = AddObject);Check(FEmpty.Items[0] = AddObject);end;end;


Test Complexity

Do the simplest thing Dave Astels: “Strive for simplicity” Write a test that fails (red) Make the test pass (green) Refactor implementation code (change the internal

design)

Use the compiler – let it tell you about errors and omissions

One assertion (Check/Assert) per test Subject of furious debate on Yahoo’s TDD group


demo

Test-driven development

using Dunit in Delphi 6

using csUnit in C#Builder


Smells

Duplication Once And Once Only (OAOO)

Setup / TearDown Some duplicated code reveals itself as common

‘initialisation’ code And / Or as ‘cleanup’ code


Agenda



Why TDD?



Why TDD? Programmers dislike testing

They will test reasonably thoroughly the first time The second time however, testing is usually less thorough The third time, well..

Testing is considered a “boring” task

Testing might be the job of another department / person

TDD encourages programmers to maintain an exhaustive set of repeatable tests

Tests live alongside the Class/Code Under Test (CUT) With tool support, tests can be run selectively The tests can be run after every single change


Why TDD?

Bob Martin: “The act of writing a unit test is

more an act of design than of verification”

Confidence boost By practicing TDD, developers will

strive to improve their code – without the fear that is normally associated with code changes

Isn’t the green bar a feel good factor?

Remove / Reduce reliance on the debugger No more “debug-later” attitudes


Who should write the tests?

The programmers should write the tests The programmers can’t wait for somebody else to write

tests

TDD promotes “small steps”, and lots of them Small steps: the shortest distance between two points Your destination is closer…

A

B


Agenda



Why TDD?



Summary

TDD does not replace traditional testing It defines a proven way that ensures effective unit testing Tests are working examples of how to invoke a piece of

code Essentially provides a working specification for the code

No code should go into production unless it has associated tests Catch bugs before they are shipped to your customer

No code without tests

Tests determine, or dictate, the code


Summary

TDD isn’t new To quote Kent Beck:

“…you type the expected output tape from a real input tape, then code until the actual results matched the expected result…”

TDD means less time spent in the debugger

TDD negates fear Fear makes developers communicate less Fear makes developers avoid repeatedly testing

code Afraid of negative feedback


Summary

TDD promotes the creation of a set of “programmer tests” Automated tests that are written by the programmer Exhaustive Can be run over and over again

TDD allows us to refactor, or change the implementation of a class, without the fear of breaking it TDD and refactoring go hand-in-hand

With care, [some] User Acceptance Tests can codified and run as part of the TDD process


Notable Quotes

Ron Jeffries, TDD and XP aficionado on the subject of TDD: “clean code that works”

Martin Fowler: “The code is the design”

Alan Francis: “Legacy code is code without tests”

To learn more about Agile Methods, Extreme Programming & Test-Driven Development visit:

http://groups.yahoo.com/group/AgileScotland


Resources (Books)

test-driven development: A Practical Guide

Dave AstelsPrentice-Hall/Pearson Education, 2003ISBN 0-13-101649-0

Reviewed BUG developers’ magazine, Nov/Dec 2003

______________________________________

Test-Driven Development: By Example

Kent BeckAddison-Wesley, 2003ISBN 0-321-14653-0


Resources (Books)

Refactoring: Improving the Design of Existing CodeMartin FowlerAddison-Wesley, 1999ISBN 0-201-48567-2


Resources (web-sites)

NUnit: http://www.nunit.org

CSUnit: http://www.csunit.org http://groups.yahoo.com/group/csunit

Mock Objects: http://www.mockobjects.com

testdrivendevelopment group (Yahoo): http://groups.yahoo.com/group/

testdrivendevelopment Ron Jeffries, Dave Astels, Kent Beck, etc. are regular

contributors


Resources (web-sites)

The DUnit group at SourceForge http://dunit.sourceforge.net

Lutz Roeder’s .NET Reflector: http://www.aisto.com/roeder/dotnet

xUnit implementations: http://www.xprogramming.com/software.htm http://www.junit.org


Resources (Articles) Test-Driven Development using csUnit in C#Builder

Craig Murphy UK-BUG Magazine Issue Jan/Feb 2004

“To err is human: automated testing of Delphi code with DUnit” Kris Golko UK-BUG Magazine Issue Nov/Dec 2002

Testing: Quality Time with DUnit Rob Bracken The Delphi Magazine, Issue 76 (Dec01)

An Introduction to Endo-Testing Using Mock Objects Sacha Frick The Delphi Magazine, Issue 96 (Aug03)


Contact and Update Information

Craig Murphy [email protected]

Updated slides, notes and source code:http://www.CraigMurphy.com


Questions?

RED

GREEN

REFACTOR

Documents

© 2001-2004 Craig Murphy Craig Murphy [email protected] An Introduction to Test-Driven Development (TDD)