TTD Test-Driven Development Create a formal, executable - - PowerPoint PPT Presentation

ttd test driven development
SMART_READER_LITE
LIVE PREVIEW

TTD Test-Driven Development Create a formal, executable - - PowerPoint PPT Presentation

TTD Test-Driven Development Create a formal, executable specification of what to do What is it TDD is a software development approach whereby you write your test cases before you write any program text TDD2 What


slide-1
SLIDE 1

TTD
 Test-Driven Development

Create a formal, executable specification of what to do

slide-2
SLIDE 2

What is it

 TDD is a software development approach whereby you write

your test cases before you write any program text

  • TDD–2
slide-3
SLIDE 3

What is it – 2

 TDD is a software development approach whereby you write

your test cases before you write any implementation program text

 You will already have defined the requirement for the class,

an initial specification for the class, and an initial design for the class

  • TDD–3
slide-4
SLIDE 4

What is it – 3

TDD is a software development approach whereby you write your test cases before you write any implementation program text

 You will already have defined the requirement for the class, an

initial specification for the class, and an initial design for the class

 Tests drive or dictate the order in which the program text is

developed

  • TDD–4
slide-5
SLIDE 5

What is it – 4

TDD is a software development approach whereby you write your test cases before you write any implementation program text

 You will already have defined the requirement for the class, an

initial specification for the class, and an initial design for the class

 Test cases dictate the order in which the program text is

developed

 By the order in which tests are satisfied

  • TDD–5
slide-6
SLIDE 6

What is it – 5

TDD is a software development approach whereby you write your test cases before you write any implementation program text

 You will already have defined the requirement for the class, an

initial specification for the class, and an initial design for the class

Test cases dictate the order in which the program text is developed

 By the order in which tests are satisfied

 The intent of the test cases is to

 Provide a formal, executable specification of what a the unit

is to do

 As a consequence, Some test cases are  A part of the specification document for independent features  A part of the design document to verify consistent and proper

implementation

  • TDD–6
slide-7
SLIDE 7

TDD stages

 Write a single test  Compile it – compilation will fail, as you have no

implementation

 Implement just enough program text to get the test to

compile

 Run the test – see it fail  Implement just enough program text to get the test to pass  Run the test and it pass  Refactor  Repeat

TDD–7

slide-8
SLIDE 8

TDD stages

TDD–8

Write a test Compile Fix compile errors Run test Watch it fail Run program test Watch it pass Run test Watch it pass Refactor & test

slide-9
SLIDE 9

How does this affect you?

 Before you write program text, think about what it will do

TDD–9

slide-10
SLIDE 10

How does this affect you? – 2

Before you write program text, think about what it will do

 Write the test cases that use methods that are not even

implemented yet

TDD–10

slide-11
SLIDE 11

How does this affect you? – 3

Before you write program text, think about what it will do

Write the test cases that use methods that are not even implemented yet

 A test is not something you do it is something you write and

run once, twice, three times, etc. etc. etc.

TDD–11

slide-12
SLIDE 12

How does this affect you? –

Before you write program text, think about what it will do

Write the test cases that use methods that are not even implemented yet

 A test is not something you do it is something you write and

run once, twice, three times, etc. etc. etc.

 It is program text – a formal, executable specification  You have test automation so you can repeatedly test your

system even after small changes (regression testing)

TDD–12

slide-13
SLIDE 13

How does this affect you? – 5

Before you write program text, think about what it will do

Write the test cases that use methods that are not even implemented yet

A test is not something you do it is something you write and run once, twice, three times, etc. etc. etc.

 It is program text – a formal, executable specification  You have test automation so you can repeatedly test your system

even after small changes (regression testing)

 If a bug is found after development, a test is created to keep

the bug from coming back

  • TDD–13
slide-14
SLIDE 14

Why TDD?

 Programmers dislike testing

TDD–14

slide-15
SLIDE 15

Why TDD? – 2

 Programmers dislike testing

 They will test reasonably thoroughly the first time  The second time is less thorough  The third time ... ??? Good luck – testing is a boring task

TDD–15

slide-16
SLIDE 16

Why TDD? – 3

 Programmers dislike testing

 They will test reasonably thoroughly the first time  The second time is less thorough  The third time ... ??? Good luck – testing is a boring task

 But programmers need to produce correct program text

 So write the tests first  Make it easy to run the tests

TDD–16

slide-17
SLIDE 17

Why TDD? – 3

 Encourages programmers to maintain an exhaustive set of

repeatable tests

TDD–17

slide-18
SLIDE 18

Why TDD? – 4

 Encourages programmers to maintain an exhaustive set of

repeatable tests

 Tests live alongside the class under test  Tests can be run frequently

 After every single change with XP (extreme

programming)

 With tool support, tests can be run selectively

 Making it reasonable to run relevant tests frequently

TDD–18

slide-19
SLIDE 19

TDD Benefits

 Fewer bugs  Program text can be refactored without fear  Continuous integration

 During development a growing subset of the system always

works

 It may not do everything required but what it does do is

right

 Program text is more maintainable in that regression testing

will find errors due to recent changes

TDD–19

slide-20
SLIDE 20

TDD–20

XP approach to testing

 The Extreme Programming approach

 Follows TDD

 Tests are written before the program text itself  If the program text has no automated test cases, it is

assumed not to work

 A testing framework is used so that automated testing

can be done

slide-21
SLIDE 21

TDD–21

XP approach to testing – 2

 So what is different?

 Testing is done extremely frequently

 After every change  This may be as often as every 5 or 10 minutes

slide-22
SLIDE 22

TDD–22

XP approach to testing – 3

 So what is different?

 Testing is done extremely frequently

 After every change  This may be as often as every 5 or 10 minutes

 A more balanced approach is to run tests frequently but after

a coherent set of changes is made