Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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