Test Driven Development TDD Presented by Victor Goldberg

  • Slides: 21
Download presentation
Test Driven Development (TDD) Presented by Victor Goldberg, Ph. D. Smalltalk Connections vmgoldberg@earthlink. net

Test Driven Development (TDD) Presented by Victor Goldberg, Ph. D. Smalltalk Connections [email protected] net 1

The Nature of our Problem Then a miracle occurs Good work, but I think

The Nature of our Problem Then a miracle occurs Good work, but I think we need more detail right here. Smalltalk Connections [email protected] net 2

What is Test Driven Development? n It’s a practice that adds reliability to the

What is Test Driven Development? n It’s a practice that adds reliability to the development process. Smalltalk Connections [email protected] net 3

Why is TDD important? n Many projects fail because they lack a good testing

Why is TDD important? n Many projects fail because they lack a good testing methodology. n It’s common sense, but it isn’t common practice. n The sense of continuous reliability and success gives you a feeling of confidence in your code, which makes programming more fun. Smalltalk Connections [email protected] net 4

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

How does it work? q Have a requirement. Let’s say “create a new random card, q q q 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 [email protected] net 5

There are different kinds of tests n Experiments (a. k. a. spikes), n Acceptance

There are different kinds of tests n Experiments (a. k. a. spikes), n Acceptance tests, n Code Behavior tests, and n Development code TDD’s main functional tests realm. We will also touch on experiments. Smalltalk Connections [email protected] net 6

A Possible Initial TDD Test (in Smalltalk [ST]) test. Card. Drawn. Is. Within. Range

A Possible Initial TDD Test (in Smalltalk [ST]) test. Card. Drawn. Is. Within. Range | number | Object Method Name Local variable Action Getter – retrieves a result of the action number : = card draw numerical. Value. self assert: ( number > 0 ) & ( number < 14 ). Smalltalk Connections [email protected] net 7

 Fig 1. The same code in the ST browser. card is in red

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 Test. Cards. assert: is a message sent to self; its argument is a Boolean. Test. Cards is a child of Test. Case, a class in the SUnit framework. Smalltalk Connections [email protected] net 8

Fig 2. When run, the test identifies an error. The assertion didn’t have the

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 [email protected] net 9

(The Card class) (The card instance) Fig 3. The Card class and card instance

(The Card class) (The card instance) Fig 3. The Card class and card instance are created. The new instance of Card is assigned to the variable card. Smalltalk Connections [email protected] net 10

Fig 4. The test still identifies an error. The card instance doesn’t recognize the

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 [email protected] net 11

Experiment Example in the Smalltalk Workspace r : = Random new. frequency : =

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 < 14 if. True: [ frequency add: result] if. False: [ ^ 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. Smalltalk Connections [email protected] net 12

Fig 6. The results of running the code twice. The distribution of values is

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 [email protected] net 13

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

Fig 7. After the experiment we feel comfortable writing #draw. In #draw we assign the result of the calculation to the instance variable numerical. Value Smalltalk Connections [email protected] net 14

Fig 8. Now the test passes. n In this case numerical. Value is a

Fig 8. Now the test passes. n In this case numerical. Value is a getter, a message sent to the card object to retrieve the contents of the instance variable numerical. Value. Smalltalk Connections [email protected] net 15

TDD is fun!!! Passing the test (the green bar) is the feedback that makes

TDD is fun!!! Passing the test (the green bar) is the feedback that makes it fun. Smalltalk Connections [email protected] net 16

Summary Smalltalk Connections vmgoldberg@earthlink. net 17

Summary Smalltalk Connections [email protected] net 17

Summary (1) In TDD: n Requirements drive the tests. n Tests drive the development

Summary (1) In TDD: n Requirements drive the tests. n Tests drive the development of the application code. n No application code is written without writing a failing test first. n Tests are collected in a suite and the suite is run frequently, like every time after code is written. n Test and code are written in elementary increments. n Refactoring is a continuous operation, and is supported by a passing battery of tests. Smalltalk Connections [email protected] net 18

Summary (2) TDD is good because it: n Reduces the number of bugs by

Summary (2) TDD is good because it: n Reduces the number of bugs by orders of magnitude, n Increases development speed, because less time is spent chasing bugs. n Improves code quality because of the increased modularity, and continuous and relentless refactoring. n Decreases maintenance costs because the code is easier to follow. Smalltalk Connections [email protected] net 19

Summary (3) In addition to all its technical contributions to a project, Test Driven

Summary (3) In addition to all its technical contributions to a project, Test Driven Development succeeds because … Smalltalk Connections [email protected] net 20

Smalltalk Connections vmgoldberg@earthlink. net 21

Smalltalk Connections [email protected] net 21