Chair ofSoftware Engineering

XP and TDDExtreme Programming and Test Driven Development

Andreas Leitner

Chair of Software EngineeringETH Zurich

May 10, 2007

Chair ofSoftware Engineering

Goal

I Have overview of software development processesI Understand what extreme programming isI Understand what unit testing isI Understand what test driven development isI Differentiate the latter from test first development

Chair ofSoftware Engineering

Outline

Development Processes Overview

Extreme Programming

Unit Testing

Test Driven Development

Chair ofSoftware Engineering

Outline

Development Processes Overview

Extreme Programming

Unit Testing

Test Driven Development

Chair ofSoftware Engineering

Development Processes Overview

I Traditional MethodsI Waterfall modelI V modelI Spiral modelI Prototype modelI ...

I Agile MethodsI Extreme ProgrammingI Test Driven DevelopmentI ...

Chair ofSoftware Engineering

Waterfall model

Figure from: Wikipedia

Chair ofSoftware Engineering

V model

SystemRequirements

SoftwareRequirements

PreliminaryDesign

DetailedDesign

Implementation

UnitTesting

IntegrationTesting

AcceptanceTesting

SystemIntegration

Chair ofSoftware Engineering

Defect Cost

Relative cost to correct a defect

0

10

20

30

40

50

60

70

Requirements Design Code DevelopmentTesting

AcceptanceTesting

Operation

Source: Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981

Chair ofSoftware Engineering

Spiral model

Figure from: Ghezzi, Jazayeri, Mandrioli, Software Engineering, 2nd edition, Prentice Hall

Chair ofSoftware Engineering

Project Management

I Programming competence varies greatlyI 1:10 in a single group (Sackman, Erikson, Grant)

I Who introduces more bugs?I Experienced DevelopersI Beginners

Chair ofSoftware Engineering

Outline

Development Processes Overview

Extreme Programming

Unit Testing

Test Driven Development

Chair ofSoftware Engineering

XP: Motivation

I Schedule slipsI Project canceledI Systems go sourI Defect rateI Doesn’t solve actual problemI Business changesI False feature richI Staff turnover

Chair ofSoftware Engineering

XP: Cost of Change

time

cost of change

traditional

XP

Chair ofSoftware Engineering

XP: Rules

I The planning gameI Small ReleasesI MetaphorI Simple DesignI TestingI RefactoringI Pair programmingI Collective OwnershipI Continuous IntegrationI 40h-WeekI On-Site CustomerI Coding Standards

Chair ofSoftware Engineering

XP: Programming in the Wild

I Is XP like “programming in the wild”?

Chair ofSoftware Engineering

Outline

Development Processes Overview

Extreme Programming

Unit Testing

Test Driven Development

Chair ofSoftware Engineering

Kinds of Testing

I Unit testingI Integration testingI System testingI Acceptance testingI Regression testing

Chair ofSoftware Engineering

Unit testing

I ToolsI SUnit – Smaltalk (first one)I JUnit – Java (www.junit.org)I cppunit – C++I PyUnit – PythonI ...

Chair ofSoftware Engineering

JUnit: Example

@Test public void simpleAdd ( ){

Money m12CHF= new Money(12 , "CHF" ) ;Money m14CHF= new Money(14 , "CHF" ) ;

Money expected= new Money(26 , "CHF" ) ;Money r e s u l t = m12CHF. add (m14CHF ) ;

asser tTrue ( expected . equals ( r e s u l t ) ) ;}

I outcome: pass or fail

Chair ofSoftware Engineering

Good Test Cases

I Test Case passes, the software is good?I Test Case fails, the software is bad?

I Revealing failure?I Revealing potential failures?I Satisfying coverage criteria?

Chair ofSoftware Engineering

Testivus On Test Coverage

by JUnit Factory, Alberto Savoia

Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverageshould I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”The programmer smiled, bowed, and left.

Chair ofSoftware Engineering

Testivus On Test Coverage

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many peopleyou need to feed, how hungry they are, what other food you areserving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

Chair ofSoftware Engineering

Testivus On Test Coverage

Toward the end of the day, a third programmer came and askedthe same question about code coverage.

“Eighty percent and no less!” Replied the master in a sternvoice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

Chair ofSoftware Engineering

Testivus On Test Coverage

After this last reply, a young apprentice approached the greatmaster:

“Great master, today I overheard you answer the same questionabout code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the greatmaster began to answer:

Chair ofSoftware Engineering

Testivus On Test Coverage

“The first programmer is new and just getting started withtesting. Right now he has a lot of code and no tests. He has along way to go; focusing on code coverage at this time wouldbe depressing and quite useless. He’s better off just gettingused to writing and running some tests. He can worry aboutcoverage later.”

“The second programmer, on the other hand, is quiteexperience both at programming and testing. When I replied byasking her how many grains of rice I should put in a pot, Ihelped her realize that the amount of testing necessarydepends on a number of factors, and she knows those factorsbetter than I do – it’s her code after all. There is no single,simple, answer, and she’s smart enough to handle the truth andwork with that.”

Chair ofSoftware Engineering

Testivus On Test Coverage

“I see,” said the young apprentice, “but if there is no singlesimple answer, then why did you answer the third programmer’Eighty percent and no less’?”

The great master laughed so hard and loud that his belly,evidence that he drank more than just green tea, flopped upand down.

“The third programmer wants only simple answers – even whenthere are no simple answers ... and then does not follow themanyway.”

The young apprentice and the grizzled great master finisheddrinking their tea in contemplative silence.

Chair ofSoftware Engineering

Outline

Development Processes Overview

Extreme Programming

Unit Testing

Test Driven Development

Chair ofSoftware Engineering

TDD: Overview

I Evolutionary approach to developmentI Combines

I Test-first developmentI Refactoring

I Primarily a method of software designI Not just method of testing

Chair ofSoftware Engineering

TDD: The Process

Chair ofSoftware Engineering

TDD = TFD + Refactoring

I Apply test-first developmentI Refactor whenever you see fit (before next functional

modification)I Think for the moment:

I Write new business code only when a test case failsI Eliminate any duplication you find

I Produce failure revealing test cases

Chair ofSoftware Engineering

TDD and Extreme Programming

I Easy to give in and skip some test casesI Pair-programming can helpI Writing testable code helps

Chair ofSoftware Engineering

TDD: Consequences

I Incremental developmentI Development environment must provide rapid response to

small changesI Components are designed highly cohesive, loosely

coupledI Developers learn to write good unit tests:

I Run fastI Run in isolationI Use data that makes test case easy to readI Each test case is step towards overall goal

Chair ofSoftware Engineering

TDD & Documentation

I Programmers often do not read documentationI Instead, they look for examples and play with themI Good unit tests can serve as

I ExamplesI Documentation

Chair ofSoftware Engineering

TDD: pros and cons

I ProsI Reduce gap between decision and feedbackI Encourage developers to write code that is easily testedI Creates a thorough test bed

I DrawbacksI Time taken away from core developmentI Some code is difficult to test

Chair ofSoftware Engineering

References

I Kent Beck: Agile software development: principles,patterns, and practices. Addision Wesley, 2003

I Astels: Test Driven Development: A Practical Guide,Prentice Hall, 2003

I Kent Beck: Extreme Programming Explained, AddisionWesley, 2000

I Bertrand Meyer: Practice to perfect: the quality first model,IEEE Computer, 30, 5, pages 102-103, 105-106, 1997

I Andrew Hunt: The Pragmatic Programmer: fromjourneyman to master. Addision Wesley, 2000

I Kent Beck: Extreme Programming explained. AddisionWesley, 2000

I by Alberto Savoia: The Way of Testivus. JUnit Factorywebpage