Testing Testing
Sep. 8th, 2003 07:31 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerAnother 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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-09-08 11:40 am (UTC)(Sometimes I go as far as to say that "the test is the requirement".)
no subject
Date: 2003-09-08 11:43 am (UTC)Re: Coverage
Date: 2003-09-08 12:20 pm (UTC)This is not from extreme programming. If you write a program, you should write tests to make sure it does what you think it should. Just as you should write documentation that tells you how to use it. If you break the system, you write a new test that covers the problem that you missed before.
XP invents testing suites
OOP invents data encapsulation
Bringing something important to the forefront is good. But to say that a methodology invented a technique that's been part of best practices is annoying...
no subject
Date: 2003-09-09 01:28 am (UTC)It's a bit tricker to apply to event driven UI stuff (too many possible paths, I know you can't hope to test all paths even in Cobol, but you know what I mean), but you can at least pin the main logic.
Goes back to the classic of speccing, it's not a valid requirement if you can't describe a pass/fail test for it.