Why write test code?
The natural state of test code is unwritten, especially when the tests are passing.
Writing test code can shift your paradigm, as completely as C++ did when I knew C, or as swiftly as C when all I knew was COBOL. Well-tested code is blocks known to fit well in certain slot-patterns. And you can hammer those blocks into any shape you like, then refactor the shine on it till it becomes less like a block, and more like a wrench. Tested code is much more likely to be re-used (because we know what it does), and re-usable (because of the hammering and polishing), and so to become more tool than block.
Writing test code helps you to see the source as source code, especially when you notice that "hard to test" co-incides with other indicators of "crap code". Tools such as profilers are much more useful when driven by a suite of tests - you can concentrate on efficiency issues only, the suite provides both safety net for experiments, and loads to push against. Tested code can be easier to use, because it has been used at least twice - in the source and in the test. Badly tested code is worse than untested code, because it hides holes in the safety net, which Mr Murphy guarantees will always be the holes the system finds when The Suits are being demoed.
Except that there is really no such thing as untested code.
All code is tested by the coder as it is written, except the parts we are sure will work. Unless deadlines are actually passing code will be run to make sure it does what we think it does. A good coder will test well on these runs, a bad coder will test less well, but few of either group will have written the tests down first. Most coders take the less than Extreme view that tests are to be written (if at all) to confirm what we already knew: that the program works. There is an element of superstition in this: searching for bugs increases the chance of their spontaneous generation. But there is also resentment of useless documentation - writing good test code will reduce the amount of source lines written by at least half, but the lines of test code will not contribute to creating the feature, and we are selling features now. Of course the benefits of testing are wider: testing contributes only indirectly to feature development (as does the compiler) and the benefits of testing are slower, tested code becomes more useful the longer it has been tested.
Is it important who wrights the test code? Yes, the programmer has unique insight into what the code is intended to do (which may be different what it is supposed to do).
In an undocumented system, the best test that can be built is of the coder's intention. More documentation is needed to discover what it is supposed to do - hmmm, shouldn't what it is supposed to do be minimum documentation for any code ?
Notes:
This is a technical term among coders, meaning source code that does not meet local coding standards
How do I know what I think till I see what I say ?
Writing test code can shift your paradigm, as completely as C++ did when I knew C, or as swiftly as C when all I knew was COBOL. Well-tested code is blocks known to fit well in certain slot-patterns. And you can hammer those blocks into any shape you like, then refactor the shine on it till it becomes less like a block, and more like a wrench. Tested code is much more likely to be re-used (because we know what it does), and re-usable (because of the hammering and polishing), and so to become more tool than block.
Writing test code helps you to see the source as source code, especially when you notice that "hard to test" co-incides with other indicators of "crap code". Tools such as profilers are much more useful when driven by a suite of tests - you can concentrate on efficiency issues only, the suite provides both safety net for experiments, and loads to push against. Tested code can be easier to use, because it has been used at least twice - in the source and in the test. Badly tested code is worse than untested code, because it hides holes in the safety net, which Mr Murphy guarantees will always be the holes the system finds when The Suits are being demoed.
Except that there is really no such thing as untested code.
All code is tested by the coder as it is written, except the parts we are sure will work. Unless deadlines are actually passing code will be run to make sure it does what we think it does. A good coder will test well on these runs, a bad coder will test less well, but few of either group will have written the tests down first. Most coders take the less than Extreme view that tests are to be written (if at all) to confirm what we already knew: that the program works. There is an element of superstition in this: searching for bugs increases the chance of their spontaneous generation. But there is also resentment of useless documentation - writing good test code will reduce the amount of source lines written by at least half, but the lines of test code will not contribute to creating the feature, and we are selling features now. Of course the benefits of testing are wider: testing contributes only indirectly to feature development (as does the compiler) and the benefits of testing are slower, tested code becomes more useful the longer it has been tested.
Is it important who wrights the test code? Yes, the programmer has unique insight into what the code is intended to do (which may be different what it is supposed to do).
In an undocumented system, the best test that can be built is of the coder's intention. More documentation is needed to discover what it is supposed to do - hmmm, shouldn't what it is supposed to do be minimum documentation for any code ?
Notes:
This is a technical term among coders, meaning source code that does not meet local coding standards
How do I know what I think till I see what I say ?
posted by Alan at 9:10 a.m.
0 Comments:
Post a Comment
<< Home