Test Driven Developm ent Brian Nielsen Arne Skou - - PowerPoint PPT Presentation

Test Driven Developm ent

Brian Nielsen Arne Skou

bnielsen@cs.aau.dk ask@cs.aau.dk

TDD D fi ifi TDD Definifion

“Test-driven Development is a programming practice that instructs developers to write new code only if an automated test has failed, and to l d l h l f eliminate duplication. The goal of TDD is clean code that works”

[ Mansel&Husted: JUnit in Action]

CISS

TDD D fi ifi

[ l ll ]

TDD Definifion

“ l h f f d [ Agile Alliance] “Test Driven Development is the craft of producing automated tests for production code, and using that process to drive design and programming that process to drive design and programming For every bit of functionality you first develop a For every bit of functionality, you first develop a test that specifies and validates what the code will do. do You then produce exactly as much code as You then produce exactly as much code as necessary to pass the test. Then you refactor (simplify and clarify) both production code and CISS test code”

P ibl t t Possible test processes

Test Last (waterfall)

Specification Write Test cases Code Impl.

Test Last (waterfall)

Write Test

Test Concurrently (i d d tl )

Specification cases

(independently)

Code Impl. Specification Write Test cases Code Impl.

Test First

CISS

cases

W h t i TDD? W hat is TDD?

h h b

 TDD is a technique whereby you write your test

cases before you write any implementation code code

 Tests drive or dictate the code that is developed  An indication of “intent”  An indication of intent

 Tests provide a specification of “what” a piece of code

actually does

 Thinking about testing is analysing what the system

should do!

 Some might argue that “tests are part of the  Some might argue that “tests are part of the

docum entation”

 Mainly Unit Testing

CISS a y U t est g

 Automated Regression Unit Testing

R i t Requirem ents

Standards Domain Experts Standards Informal understanding in developer’s mind

CISS

Written specs (iinformal, ncomplete, ambiguous) Customers

A t t d T ti Autom ated Testing

 “Code that isn’t tested doesn’t work”  “Code that isn’t regression tested suffers

g from code rot (breaks eventually)”

 “If it is not automated it is not done!”

If it is not automated it is not done!

 “A unit testing framework enables

efficient and effective unit & regression efficient and effective unit & regression testing P F i dl

 Programmer Friendly

CISS

R i t ti Regression testing

 New code and changes to old code can

affect the rest of the code base

 “Affect” sometimes means “break”

 Regression = Relapsed to a less perfect

g p p

• r developed state.

 Regression testing: Check that code  Regression testing: Check that code

has not regressed

 Regression testing is required for a  Regression testing is required for a

stable, maintainable code base

CISS

R f t i Refactoring

 Refactoring is a behavior preserving

transformation

 Restructure, simplify, beautify  Refactoring is an excellent way to break

Refactoring is an excellent way to break code.

CISS

T ti i U it Testing using xUnit

Refactor code tests [ Pass]

All t t S t t

tests [ Pass] Refactor code tests [ Fail]

All tests pass Some tests fail

Fix code

p

Can’t think of t t Write Failed test any more tests

CISS

B fit ? Benefits?

ff

 Efficiency

 Identify defects earlier  Identify cause more easily  Identify cause more easily

 Higher value of test effort

 Producing a more reliable system  Producing a more reliable system  Improve quality of testing (maintain automated tests)  Minimization of schedule  Stable code base

 Reducing Defect Injection

 Small “fixes” have are 40 times more error prone than

new code = > Fine grained tests + run tests continuously

CISS

co t uous y

B fit ? Benefits?

 Better programmer Life

 Can now work on your code with no fear;  No one wants to support a fragile system;

• “We don’t touch that, it might break.”

 With complete tests code away:  With complete tests, code away:

• Test fails, you * know* you broke something.
• Tests pass, you didn’t.

 Eases changes (XP embrace change):

 addition of functionality  addition of functionality  new requirements  refactoring

CISS

 refactoring

TDD St TDD Stages



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

1

Write a single test

1.

Write a single test

2.

Compile it. It shouldn’t compile because you’ve not written the implementation code

3.

Implement just enough code to get the test to compile

4.

Run the test and see it fail I l t j t h d t t th t t t

5.

Implement just enough code to get the test to pass

6.

Run the test and see it pass

7

Refactor for clarity and “once and only once”

7 .

Refactor for clarity and once and only once

8.

Repeat

CISS

D l t C l Developm ent Cycle

add a test th t t

[Pass]

run the test

[Fail] [ Pass] Development continues

add functionality

[Fail] continues

run the test

[Fail]

CISS

[Development stops]

TDD Exam ple Si l Li ht C t ll Sim ple Light-Controller

 Light controller toggles light on/ off when

wire is touched

switch On Off switch

CISS

TDD E l TDD Exam ple

i d i h( ) {

• Writing test case first

voi d t est Swi t ch( ) { s=new Li ght Swi t ch( ) ; check( s! =NULL) ; check( O N == s swi t ch( ) ) ; check( O N == s. swi t ch( ) ) ; check( O FF ==s. swi t ch( ) ) ; check( O N == s. swi t ch( ) ) ; }

• Run tests: (Fails: compilation errors)

( p )

• LightSwitch doesn’t exist

CISS

TDD E l TDD Exam ple

• Write a first simple implementation

Cl ass Li ght Swi t ch { publ i c enum Li ght St at e { O N, O FF} st at e; publ i c Li ght Swi t ch( ) { st at e=O FF; } Li ght St at e swi t ch( ) { Ret ur n st at e; } }

• Run Tests
• System Compiles

T t till f il ( fi t h k) CISS

• Test still fails (passes first check)
• Switch not fully implemented

TDD E l TDD Exam ple

• Implement switch-method

Cl ass Li ght Swi t ch { Cl ass Li ght Swi t ch { Cl ass Li ght Swi t ch { Cl ass Li ght Swi t ch { publ i c enum Li ght St a publ i c enum Li ght St at e { O N, O FF} st at e; t e { O N, O FF} st at e; publ i c enum Li ght St a publ i c enum Li ght St at e { O N, O FF} st at e; t e { O N, O FF} st at e; publ i c Li ght Swi t c publ i c Li ght Swi t ch( ) { st at e=O FF; } h( ) { st at e=O FF; } publ i c Li ght Swi t c publ i c Li ght Swi t ch( ) { st at e=O FF; } h( ) { st at e=O FF; } Li ght St at e swi t ch( ) { Li ght St at e swi t ch( ) { Li ght St at e swi t ch( ) { Li ght St at e swi t ch( ) { i f ( st at e==O FF) st at e=O N; i f ( st at e==O FF) st at e=O N; i f ( st at e==O FF) st at e=O N; i f ( st at e==O FF) st at e=O N; i f ( st at e==O N i f ( st at e==O N) st at e=O FF; ) st at e=O FF; i f ( st at e==O N i f ( st at e==O N) st at e=O FF; ) st at e=O FF; r et ur n st at e r et ur n st at e; r et ur n st at e r et ur n st at e; } }

• Run Test
• still fails (passes first two checks)

S it h i t CISS

• Switch incorrect

TDD E l TDD Exam ple

• Rewrite switch-method (perhaps refactor)

Cl ass Li ght Swi t ch { publ i c enum Li ght St at e { O N, O FF} st at e; publ i c Li ght Swi t ch( ) { st at e=O FF; } publ i c Li ght St at e swi t ch( ) { i f ( st at e==O N) i f ( st at e==O N) st at e=O FF; st at e=O FF; el se el se st at e=O N; st at e=O N; r et ur n st at e; } }

• Run Tests: Test Passes

CISS Run Tests: Test Passes

TDD E l TDD Exam ple

 Light controller toggles light on/ off when

wire is touched

 New Requirem ent: When wire is held

the controller decrements the light level g

switch

dim dim

Bright Dim1 Dim2 Off

dim dim

CISS

switch

TDD E l TDD Exam ple

• Add test case for new functionality

voi d t est Swi t ch( ) { voi d t est Swi t ch( ) { voi d t est Swi t ch( ) { voi d t est Swi t ch( ) {

s=new Li ght Swi t ch( ) ; s=new Li ght Swi t ch( ) ; check( s! NULL) check( s! NULL)

Add test case for new functionality

check( s! =NULL) ; check( s! =NULL) ; check( O N == s. swi t ch( ) ) ; check( O N == s. swi t ch( ) ) ; check( O FF ==s. swi t ch( ) ) ; check( O FF ==s. swi t ch( ) ) ; check( O N == s. swi t ch( ) ) ; check( O N == s. swi t ch( ) ) ;

} voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { voi d t est Di m m er ( ) { s=new Li ght Swi t ch( ) ; / / i ni t i al l y of f s=new Li ght Swi t ch( ) ; / / i ni t i al l y of f check( s. get Level ( ) ==0) ; check( s. get Level ( ) ==0) ;

• s. di m

( ) ; / / No ef f ect when of f

• s. di m

( ) ; / / No ef f ect when of f ( ) ; / / ( ) ; / / check( s. get Level ( ) ==0) ; check( s. get Level ( ) ==0) ;

• s. swi t ch( ) ; / / swi t ch on: l evel i s M

ax: 3

• s. swi t ch( ) ; / / swi t ch on: l evel i s M

ax: 3 check(s.getLevel()= = 3); check(s.getLevel()= = 3); s dim(); s dim(); s.dim(); s.dim(); check(s.getLevel()= = 2); / / dimming works check(s.getLevel()= = 2); / / dimming works s.dim(); s.dim(); check(s.getLevel()= = 1); check(s.getLevel()= = 1);

CISS

c ec (s get e e () ); c ec (s get e e () ); s.dim(); s.dim(); check(s.getLevel()= = 1); / / cannot dim more check(s.getLevel()= = 1); / / cannot dim more }

TDD E l TDD Exam ple

• Write Implementation

Cl ass Li ght Swi t ch { Cl ass Li ght Swi t ch { publ i c enum Li ght St at e { O N, O FF} st at e; publ i c Li ght Swi t ch( ) { st at e=O FF; }

Write Implementation

publ i c Li ght Swi t ch( ) { st at e=O FF; } i nt l evel ; i nt l evel ; publ i c i nt get Level publ i c i nt get Level ( ) { r et ur n l evel ; } ( ) { r et ur n l evel ; } publ i c voi d di m ( ) { publ i c voi d di m ( ) { i f ( st at e==O N && i f ( st at e==O N && l evel >1) l evel l evel >1) l evel ; i f ( st at e==O N && i f ( st at e==O N && l evel >1) l evel l evel >1) l evel - -

• - ;

} publ i c Li ght St at e swi t ch( ) { i f ( st at e==O N) { { / / changed code st at e st at e O N; O N; st at e st at e=O N; O N; l evel =0; l evel =0; } el se { } el se { st at e=O N; st at e=O N; l l l l 3 l eve evel =3; } } r et ur n st at e; } } } }

CISS

• Run Tests: testDim Passes, but testSw itch

fail

TDD E l TDD Exam ple

• Fix Error

Cl ass Li ght Swi t ch { Cl ass Li ght Swi t ch { publ i c enum Li ght St at e { O N, O FF} st at e; publ i c Li ght Swi t ch( ) { st at e=O FF; }

Fix Error

publ i c Li ght Swi t ch( ) { st at e=O FF; } i nt l evel ; i nt l evel ; publ i c i nt get Level publ i c i nt get Level ( ) { r et ur n l evel ; } ( ) { r et ur n l evel ; } publ i c voi d di m ( ) { publ i c voi d di m ( ) { i f ( st at e==O N && i f ( st at e==O N && l evel >1) l evel l evel >1) l evel ; i f ( st at e==O N && i f ( st at e==O N && l evel >1) l evel l evel >1) l evel - -

• - ;

} publ i c Li ght St at e swi t ch( ) { i f ( st at e==O N) { { / / changed code st at e st at e O FF; O FF; st at e st at e=O FF; O FF; l evel =0; l evel =0; } el se { } el se { st at e=O N; st at e=O N; l l l l 3 l eve evel =3; } } r et ur n st at e; } } } }

CISS

• Run Tests: Both testSw itch and testDim passes

A C St d A Case Study

 Device Drivers at IBM [ Williams, Maximilien, Vouk ’03]

• None experienced in TDD

CISS

R lt Results

 40% reduction in defect  40% reduction in defect

density (external test team)

 Identical severity

distribution A i t l d ti it

 Approximately same productivity

 Developers spend more time writing test cases, but

reduces time spent on (unpredictable) debugging reduces time spent on (unpredictable) debugging

 64.6 KLOC new code + 34 KLOC JUnit tests

 “We belive that TDD aided us in producing a product that

CISS

more easily incorporated later changes”

B k d f TDD Background for TDD

E d f A il d Xt

 Emerged from Agile and eXtreme

Programming (XP) methods XP P ti

 XP Practices

 Incremental

C ti I t ti

 Continuous Integration  Design Through Refactoring  Collective Ownership  Collective Ownership  Programmer Courage

 Lightweight development process  Lightweight development process  K. Beck: “XP takes best practices and

turns all knobs up to 10!”

CISS

turns all knobs up to 10!

B k Books

test-driven developm ent: A Practical Guide

Dave Astels Prentice-Hall/ Pearson Education, 2003 ISBN 0-13-101649-0 Reviewed BUG developers’ magazine, Nov/ Dec 2003

______________________________________ Test-Driven Developm ent: By Exam ple

Kent Beck Addison-Wesley, 2003 Addison Wesley, 2003 ISBN 0-321-14653-0

CISS

R ( B k ) Resources ( Books)

Refactoring: I m proving the Design of Existing Code Existing Code

Martin Fowler Addison-Wesley, 1999 ISBN 0-201-48567-2

CISS

ISBN 0 201 48567 2

R f d li k References and links

 S. Amber. Introduction to Test Driven

Development (TDD). www.agiledata.org

 D. Jansen and H. Saiedian. Test-Driven

Development: Concepts, Taxonomy and Future

• Direction. IEEE Computer September 2005

p p

 E. M. Maximilien and L. Williams. Assessing

Test-Driven Development at IBM. 25th International Conference on Software International Conference on Software Engineering, 2003

 K. Beck and E. Gama. Test infected:

Programmers love writing tests Java Report Programmers love writing tests. Java Report, 3(7), July 1998

 http: / / www.testdriven.com

CISS

 http: / / www.junit.org

Sum m ary

TDD = T t fi t Test first + A t t d ( U it) T ti Autom ated ( Unit) Testing RED RED GREEN GREEN GREEN GREEN REFACTO REFACTOR CISS GREEN GREEN

End