XP and TDD Extreme Programming and Test Driven Development Andreas - - PowerPoint PPT Presentation

xp and tdd
SMART_READER_LITE
LIVE PREVIEW

XP and TDD Extreme Programming and Test Driven Development Andreas - - PowerPoint PPT Presentation

XP and TDD Extreme Programming and Test Driven Development Andreas Leitner Chair of Software Engineering ETH Zurich May 10, 2007 Chair of Software Engineering Goal Have overview of software development processes Understand what


slide-1
SLIDE 1

Chair of Software Engineering

XP and TDD

Extreme Programming and Test Driven Development Andreas Leitner

Chair of Software Engineering ETH Zurich

May 10, 2007

slide-2
SLIDE 2

Chair of Software Engineering

Goal

◮ Have overview of software development processes ◮ Understand what extreme programming is ◮ Understand what unit testing is ◮ Understand what test driven development is ◮ Differentiate the latter from test first development

slide-3
SLIDE 3

Chair of Software Engineering

Outline

Development Processes Overview Extreme Programming Unit Testing Test Driven Development

slide-4
SLIDE 4

Chair of Software Engineering

Outline

Development Processes Overview Extreme Programming Unit Testing Test Driven Development

slide-5
SLIDE 5

Chair of Software Engineering

Development Processes Overview

◮ Traditional Methods

◮ Waterfall model ◮ V model ◮ Spiral model ◮ Prototype model ◮ ...

◮ Agile Methods

◮ Extreme Programming ◮ Test Driven Development ◮ ...

slide-6
SLIDE 6

Chair of Software Engineering

Waterfall model

Figure from: Wikipedia

slide-7
SLIDE 7

Chair of Software Engineering

V model

System Requirements Software Requirements Preliminary Design Detailed Design Implementation Unit Testing Integration Testing Acceptance Testing System Integration

slide-8
SLIDE 8

Chair of Software Engineering

Defect Cost

Relative cost to correct a defect

10 20 30 40 50 60 70 Requirements Design Code Development Testing Acceptance Testing Operation

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

slide-9
SLIDE 9

Chair of Software Engineering

Spiral model

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

slide-10
SLIDE 10

Chair of Software Engineering

Project Management

◮ Programming competence varies greatly

◮ 1:10 in a single group (Sackman, Erikson, Grant)

◮ Who introduces more bugs?

◮ Experienced Developers ◮ Beginners

slide-11
SLIDE 11

Chair of Software Engineering

Outline

Development Processes Overview Extreme Programming Unit Testing Test Driven Development

slide-12
SLIDE 12

Chair of Software Engineering

XP: Motivation

◮ Schedule slips ◮ Project canceled ◮ Systems go sour ◮ Defect rate ◮ Doesn’t solve actual problem ◮ Business changes ◮ False feature rich ◮ Staff turnover

slide-13
SLIDE 13

Chair of Software Engineering

XP: Cost of Change

time cost of change traditional XP

slide-14
SLIDE 14

Chair of Software Engineering

XP: Rules

◮ The planning game ◮ Small Releases ◮ Metaphor ◮ Simple Design ◮ Testing ◮ Refactoring ◮ Pair programming ◮ Collective Ownership ◮ Continuous Integration ◮ 40h-Week ◮ On-Site Customer ◮ Coding Standards

slide-15
SLIDE 15

Chair of Software Engineering

XP: Programming in the Wild

◮ Is XP like “programming in the wild”?

slide-16
SLIDE 16

Chair of Software Engineering

Outline

Development Processes Overview Extreme Programming Unit Testing Test Driven Development

slide-17
SLIDE 17

Chair of Software Engineering

Kinds of Testing

◮ Unit testing ◮ Integration testing ◮ System testing ◮ Acceptance testing ◮ Regression testing

slide-18
SLIDE 18

Chair of Software Engineering

Unit testing

◮ Tools

◮ SUnit – Smaltalk (first one) ◮ JUnit – Java (www.junit.org) ◮ cppunit – C++ ◮ PyUnit – Python ◮ ...

slide-19
SLIDE 19

Chair of Software 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) ; assertTrue ( expected . equals ( r e s u l t ) ) ; }

◮ outcome: pass or fail

slide-20
SLIDE 20

Chair of Software Engineering

Good Test Cases

◮ Test Case passes, the software is good? ◮ Test Case fails, the software is bad? ◮ Revealing failure? ◮ Revealing potential failures? ◮ Satisfying coverage criteria?

slide-21
SLIDE 21

Chair of Software 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 coverage should I aim for?” The great master replied: “Don’t worry about coverage, just write some good tests.” The programmer smiled, bowed, and left.

slide-22
SLIDE 22

Chair of Software 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 people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.” “Exactly,” said the great master. The second programmer smiled, bowed, and left.

slide-23
SLIDE 23

Chair of Software Engineering

Testivus On Test Coverage

Toward the end of the day, a third programmer came and asked the same question about code coverage. “Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table. The third programmer smiled, bowed, and left.

slide-24
SLIDE 24

Chair of Software Engineering

Testivus On Test Coverage

After this last reply, a young apprentice approached the great master: “Great master, today I overheard you answer the same question about 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 great master began to answer:

slide-25
SLIDE 25

Chair of Software Engineering

Testivus On Test Coverage

“The first programmer is new and just getting started with

  • testing. Right now he has a lot of code and no tests. He has a

long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.” “The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

slide-26
SLIDE 26

Chair of Software Engineering

Testivus On Test Coverage

“I see,” said the young apprentice, “but if there is no single simple 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 up and down. “The third programmer wants only simple answers – even when there are no simple answers ... and then does not follow them anyway.” The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

slide-27
SLIDE 27

Chair of Software Engineering

Outline

Development Processes Overview Extreme Programming Unit Testing Test Driven Development

slide-28
SLIDE 28

Chair of Software Engineering

TDD: Overview

◮ Evolutionary approach to development ◮ Combines

◮ Test-first development ◮ Refactoring

◮ Primarily a method of software design

◮ Not just method of testing

slide-29
SLIDE 29

Chair of Software Engineering

TDD: The Process

slide-30
SLIDE 30

Chair of Software Engineering

TDD = TFD + Refactoring

◮ Apply test-first development ◮ Refactor whenever you see fit (before next functional

modification)

◮ Think for the moment:

◮ Write new business code only when a test case fails ◮ Eliminate any duplication you find

◮ Produce failure revealing test cases

slide-31
SLIDE 31

Chair of Software Engineering

TDD and Extreme Programming

◮ Easy to give in and skip some test cases ◮ Pair-programming can help ◮ Writing testable code helps

slide-32
SLIDE 32

Chair of Software Engineering

TDD: Consequences

◮ Incremental development ◮ Development environment must provide rapid response to

small changes

◮ Components are designed highly cohesive, loosely

coupled

◮ Developers learn to write good unit tests:

◮ Run fast ◮ Run in isolation ◮ Use data that makes test case easy to read ◮ Each test case is step towards overall goal

slide-33
SLIDE 33

Chair of Software Engineering

TDD & Documentation

◮ Programmers often do not read documentation ◮ Instead, they look for examples and play with them ◮ Good unit tests can serve as

◮ Examples ◮ Documentation

slide-34
SLIDE 34

Chair of Software Engineering

TDD: pros and cons

◮ Pros

◮ Reduce gap between decision and feedback ◮ Encourage developers to write code that is easily tested ◮ Creates a thorough test bed

◮ Drawbacks

◮ Time taken away from core development ◮ Some code is difficult to test

slide-35
SLIDE 35

Chair of Software Engineering

References

◮ Kent Beck: Agile software development: principles,

patterns, and practices. Addision Wesley, 2003

◮ Astels: Test Driven Development: A Practical Guide,

Prentice Hall, 2003

◮ Kent Beck: Extreme Programming Explained, Addision

Wesley, 2000

◮ Bertrand Meyer: Practice to perfect: the quality first model,

IEEE Computer, 30, 5, pages 102-103, 105-106, 1997

◮ Andrew Hunt: The Pragmatic Programmer: from

journeyman to master. Addision Wesley, 2000

◮ Kent Beck: Extreme Programming explained. Addision

Wesley, 2000

◮ by Alberto Savoia: The Way of Testivus. JUnit Factory

webpage