SWC2013TDD » History » Version 5

Chris Cannam, 2013-02-05 08:03 PM

1 1 Chris Cannam
h1. Test-driven development outline
2 2 Chris Cannam
3 2 Chris Cannam
We assume that the "intro to Python" section has at least introduced how you would run a Python program and compare the output against an external source of "correct" results; also that the NumPy/audiofile section has shown how to suck in an entire (mono) audio file as a NumPy array.
4 2 Chris Cannam
5 2 Chris Cannam
We'll refer first back to the "intro to Python" example, with the text file of dates and observations.
6 3 Chris Cannam
7 3 Chris Cannam
<pre>
8 3 Chris Cannam
Date,Species,Count
9 3 Chris Cannam
2012.04.28,marlin,2
10 3 Chris Cannam
2012.04.28,turtle,1
11 3 Chris Cannam
2012.04.28,shark,3
12 3 Chris Cannam
# I think it was a Marlin... luis
13 3 Chris Cannam
2012.04.27,marlin,4
14 3 Chris Cannam
</pre>
15 3 Chris Cannam
16 3 Chris Cannam
We have our program that prints out the number of marlin.
17 3 Chris Cannam
18 3 Chris Cannam
<pre>
19 3 Chris Cannam
$ python count-marlin.py
20 4 Chris Cannam
2
21 3 Chris Cannam
$
22 3 Chris Cannam
</pre>
23 5 Chris Cannam
24 5 Chris Cannam
We can check this against some human-generated output, or the result of "grep" or something if the program is simple enough, in order to see whether it produces the right result. But what if we change the program to add a new feature -- will we remember to check all the old behaviour as well and make sure we haven't broken it? What if the program as a whole is so complex and subtle that we don't actually know what its output will be?
25 5 Chris Cannam
26 5 Chris Cannam
We need to do two things:
27 5 Chris Cannam
28 5 Chris Cannam
# automate the tests, and
29 5 Chris Cannam
# make sure we test the individual components that the program is made up of (so we can be reassured about its behaviour even when we don't know what the program as a whole should produce)