Test Driven Development (TDD)

Post on 22-Feb-2016

75 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Test Driven Development (TDD). Presented by Victor Goldberg, Ph.D. The Nature of our Problem. Then a miracle occurs. Good work, but I think we need more detail right here. What is Test Driven Development?. It’s a practice that adds reliability to the development process. . - PowerPoint PPT Presentation

Transcript

Smalltalk Connections vmgoldberg@earthlink.net

1

Test Driven Development (TDD)

Presented by  

Victor Goldberg, Ph.D.

Smalltalk Connections vmgoldberg@earthlink.net

2

The Nature of our Problem

Then a miracle occurs

Good work, but I think we need more detail right here.

Smalltalk Connections vmgoldberg@earthlink.net

3

What is Test Driven Development?

It’s a practice that adds reliability to the development process.

Smalltalk Connections vmgoldberg@earthlink.net

4

Why is TDD important?

 Many projects fail because they lack a good testing methodology.

  It’s common sense, but it isn’t common

practice.

The sense of continuous reliability and success gives you a feeling of confidence in your code, which makes programming more fun.

Smalltalk Connections vmgoldberg@earthlink.net

5

How does it work? Have a requirement. Let’s say “create a new random card,

as for a card game”. Think about what could be a reasonable test to verify

compliance with the requirement. Write the test before writing the code. Of course, the test

will fail, and that’s ok. Keep things simple. Then, write only the minimally necessary code to make the

test pass. This is a process of discovery; as you identify possible

improvements, refactor your code relentlessly to implement them.

Build, keep, and frequently run your cumulative collection of tests.

Smalltalk Connections vmgoldberg@earthlink.net

6

There are different kinds of tests

Experiments (a.k.a. spikes),

Acceptance tests,

Code Behavior tests, and Development code TDD’s main

functional tests realm.   We will also touch on experiments.

Smalltalk Connections vmgoldberg@earthlink.net

7

A Possible Initial TDD Test(in Smalltalk [ST])

testCardDrawnIsWithinRange

| number | 

number := card draw numericalValue .self assert: ( number > 0 ) & ( number < 14 ) .

Local variableObject Action Getter – retrieves a

result of the action

Method Name

Smalltalk Connections vmgoldberg@earthlink.net

8

Fig 1. The same code in the ST browser.  card is in red because the system doesn’t recognize such an

object. self is an instance of the class TestCards. assert: is a message sent to self; its argument is a Boolean. TestCards is a child of TestCase, a class in the SUnit framework.

Smalltalk Connections vmgoldberg@earthlink.net

9

Fig 2. When run, the test identifies an error. 

The assertion didn’t have the opportunity to fail, because an error was identified before the assertion was applied.

Smalltalk Connections vmgoldberg@earthlink.net

10

Fig 3. The Card class and card instance are created.

The new instance of Card is assigned to the variable card.

(The Card class)(The card instance)

Smalltalk Connections vmgoldberg@earthlink.net

11

Fig 4. The test still identifies an error. The card instance doesn’t recognize the method #draw.Designing #draw requires some skill.We will develop the skill through an experiment.

Smalltalk Connections vmgoldberg@earthlink.net

12

Experiment Example in the Smalltalk Workspace

r := Random new . frequency := Bag new. "Variables typing"

1 to: 1000000 do: [ :index | |result | 

result := (r next * 13) floor + 1.result >0 & result < 14ifTrue: [ frequency add: result]ifFalse: [ ^ Dialog warn: 'Result out of range' ] .] .^ frequency contents.

Fig. 5 The ST Workspace is like scratch paper, a place to experiment. 

The experiment here is to find whether our formula for random numbers is acceptable.

Fig 6. The results of running the code twice.The distribution of values is in the same range for each outcome, but different for each run. All are within [1, 13]. So, we are confident that our coding of the math is correct.

Smalltalk Connections vmgoldberg@earthlink.net

14

Fig 7. After the experiment we feel comfortable writing #draw.

In #draw we assign the result of the calculation to the instance variable numericalValue

Smalltalk Connections vmgoldberg@earthlink.net

15

Fig 8. Now the test passes. 

In this case numericalValue is a getter, a message sent to the card object to retrieve the contents of the instance variable numericalValue.

Smalltalk Connections vmgoldberg@earthlink.net

16

TDD is fun!!!

Passing the test(the green bar)is the feedback

that makes it fun.  

Smalltalk Connections vmgoldberg@earthlink.net

17

Summary

Smalltalk Connections vmgoldberg@earthlink.net

18

Summary (1)

In TDD:

Requirements drive the tests. Tests drive the development of the application code. No application code is written without writing a failing

test first. Tests are collected in a suite and the suite is run

frequently, like every time after code is written. Test and code are written in elementary increments. Refactoring is a continuous operation, and is

supported by a passing battery of tests.

Smalltalk Connections vmgoldberg@earthlink.net

19

Summary (2)

TDD is good because it:

Reduces the number of bugs by orders of magnitude, Increases development speed, because less time is

spent chasing bugs. Improves code quality because of the increased

modularity, and continuous and relentless refactoring. Decreases maintenance costs because the code is

easier to follow.

Smalltalk Connections vmgoldberg@earthlink.net

20

Summary (3)

In addition to all its technical contributions to a project,

 Test Driven Development succeeds because …

top related