I hate writing tests. Tests are awful and I'm awful at it. I just spent two hours writing the most basic tests for XML::SAX::Writer (v0.39 headed for CPAN), caught a bunch of bugs along the way (which proves just how much tests are needed), and my head hurts with repetitive concept syndrome.
And as I said, I've still only tested the most basic parts. That is, the means to output XML should work, but there's no guarantee that the XML itself is good. There are many more tests I need to write, and of a much harder kind.
I wish I could buy into all that XP thing, or other methodologies that emphasize testing before you even have something. I really wish I could but my brain just doesn't work that way. XML::SAX::Writer is a particularly bad example because I needed it immediately, and so wrote it without having the time to test anything more than what I needed that very second. After that there was a long time during which I didn't have time to touch it much. And of course, there were bugs, tons of them. Very bad and very scary ones :) I'm considering handing it over to someone with more "copious spare time" and better knowledge of some parts of Perl that I don't normally use (Matt volunteered) but a few people objected to the idea of me walking away from it so I'm holding my decision right now to see if I have the time and competence to do this and all the other things.
In any case, I hope this version with its small complement of tests will fare better than the previous ones.
I'm still not fully transmorgified into a test-first programmer, but IME it can be a learned behavior. With enough practice and motivations -- which it sounds like you've already found -- it becomes easier and easier to do. The big motivations are when you find yourself saying "Wow, writing tests for that really saved my ass."
A nice side-effect is that I wind up creating simpler interfaces and only creating what I need at that time.
Re:Hardwired vs learned
chromatic on 2002-01-16T22:25:14
I agree -- just like socket programming or XML processing or XS (maybe), the more you write tests, the more you'll understand them and the easier they are to write. It's also really nice to have the immediate "this works!"/"this breaks!" feedback a comprehensive suite gives you.Schwern once said that people panic and go into dummy mode when confronted with writing tests. Good programming practices go out the window. Sure, there's untestable stuff, but if I can test Term::Complete without changing the interface, someone who's allowed to control the interface can certainly write tests for something with less effects.
:) Re:Hardwired vs learned
darobin on 2002-01-17T13:47:37
Thanks for the encouragement, but I'm still doubtful that I'll get to become a test-first guy. The problem is that the way I work (for anything) is mull, mull, mull, then braindump. If that braindump happens to be good, then it's good; if not I throw away. I don't see myself changing that to mull, mull, test, then braindump; especially as, in truth, it is the mulling I enjoy much more than the actual coding
;-) I guess that's what happens when a french intellectual turns to hacking... There's also the fact that the only time I tried the test-first approach, I did get something that was totally bug free but I found out soon that the design I'd chosen was completely flawed (and that couldn't be caught by the tests). My overall impression was that I'd spent far more time coding than I would if I'd written the actual code before the tests. I know that's a local experience, but it didn't help convince me (motivation-wise) that that was the right approach.
However, for the two latest projects that I started working on I've moved tests to the same position as docs. That is, as soon as I've finished a piece of code I write docs and tests, while it's fresh. That usually singles out a fair number of errors.
