On Mon, 22 Feb 2010 04:45:40 -0800 (PST) "Edward K. Ream" <[email protected]> wrote:
> Unit tests are not just for testing! [snip] > P.S. I expect three possible responses to this post, and the longer > post: > > 1. Yeah, I knew that. Welcome to the club of highly effective > programmers. > > 2. Wow! I didn't know that. This is going to change my life. > > 3. Huh? I have no idea what you are talking about. Your writing > sucks. Can't you do a better job of explaining your ideas? 4. I read your post, and thought, again, I really need to try these unit test things. Random thoughts. I think you main point was about test driven design, but you spent a lot of time emphasizing that unit tests are able to pay permanent attention to possible issues, i.e. that they never forget to check things. Which obscured the test driven design part a bit, even though permanent attention is also a valuable part of unit tests. Writing unit tests to make sure that a bug which was reported in the wild does not recur is useful, but not a great advertisement for unit tests, seeing they didn't prevent the bug hitting the user. You post wasn't about that, but a lot of the other unit test mentions here are. So basically, you want code that, given X, produces Y. You write a test which would test such a piece of code, if it existed, and then write the code. The unit test approach has provided a probably valuable chance to think about / clarify the design, and it continues to provide value by catching anything that breaks the designed functionality. I think what holds me back from using unit tests more is the difficulty in writing the tests themselves (not the testing framework). A lot of code I write has some sort of server / client (web or sql server) aspect which makes constructing a pretend X fiddly. Not that it can't be done, just that it takes time, and is complex enough to be bug prone itself. And my work timeframes are not conducive to giving things the time and attention they need. When I write something with simpler inputs and outputs, like a parser for all the conceivable variations on postgres://foo:[email protected]:5432/dbname.schemaname.tablename then chances are I would write a simple test. And I'm not sure they help with everything. I spent an hour last night trying to work out why my generic code for comparing two databases for differences (after dual entry for QA) wasn't working. This is an example of a complex X. In the end the problem was forgetting how the record location reporting function worked, and so not setting some parameters it needed. I.e. it was working perfectly, I was just using it wrong. I expect some variation on the following response to this post :-) : You should break the problem down into smaller pieces and if you understood it properly it would be easier to write unit tests and they'd be valuable. This is probably true. Cheers -Terry -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
