4. 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.
5. 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.
6. 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.
7. 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 variable
Object Action Getter – retrieves a
result of the action
Method Name
8. 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.
11. 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.
12. 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 < 14
ifTrue: [ 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.
13. 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.
18. 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.
19. 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.
