Testing Testing

[andrewducker]

Another good thing from Extreme Programming - testing suites. The idea is that you create a test suite for each program _before_ you create it. Your program is working only when it passes all of the tests. You add tests as you spot possible ones during the coding and re-run the tests whenever you change the code.

I was handed an old COBOL program, written in he COBOL-74 standard (as in 1973) and told to bring it up to date in COBOL-85 (and yes, there is a COBOL 2000, but we're not getting that for another year or two). I did a bit of rewriting before I realised that while I was pretty sure that my changes so far hadn't changed functionality, I couldn't be 100% sure. So I wrote a test suite to call the program with 15 different combinations of data (it's a fairly simple program) and made sure that the tests all passed ok. Then, whenever I refactored some code after that, I'd recompile and re-test. If the test suite passed, that meant that my new code hadn't done anything seriously different. I added a few tests as I went along, when my changes added new branches into the code.

Because I knew that my changes definitely worked, I felt far less worried about the effects my code changes were having. I could happily move whole chunks around, provided I re-ran the tests straight afterwards to spot any errors that had crept in. A 150-line program swiftly became a 30 line program - and I know that it's right, because it does exactly the same as the old program did with the same data.

I'll definitely be doing more of that in the future.

Comments

[juuro.livejournal.com]

As a customer representative in a number of software projects, I highly applaud this kind of thinking. Well done!

(Sometimes I go as far as to say that "the test is the requirement".)

[andrewducker]

I wouldn't go that far - there are always more tests to be thought of, but the tests should definitely be there as indicators of the scope of the requirement.