Thursday, October 06, 2005

Double Entry Bookkeeping

I don't remember if I mentioned this on my blog, or someone else's, but I view TDD as double entry bookkeeping. Apparently, Uncle Bob does, too.

Update: it was on my blog.


Andy said...

I think TDD *can* be double entry book-keeping if someone else writes the test cases and maintains the test suite. I think too ofter than those are maintained by the same developers that create/maintain a system, and you get back to a system where you are proofing your own stuff.

Tanton said...

Well, if you take to XP programming, then there are always two people. But, even without XP, it is almost like there are two people, since your writing the specification before you ever write the code, it is hard to overlook edge conditions because you can't write the code to cause them without writing tests first.

Andy said...

I agree that it is a better approach to take when in a single-person aspect, but I know that I really try to get other people to proof documents that I write. I think the same should be done with any code that I write, too in that someone else should be writing the tests for it.

How often have you written something (and even tested it) only to see someone try and use your software in such a way that was not thought of? I think that TDD might help you catch some of the dumb errors, but would still be prone to that you as a programmer know how things should be, not how they are.

Tanton said...

Reminds me of Romans 6:1 - "Let's continue in sin, that grace may abound." I know what you are getting at, someone else should write the tests because they have an unbiased viewpoint. XP has the business analyst writing the acceptance tests, since he is the one responsible for saying what it should do. The coder, who is intimate with the lower level details, is the one writing the unit tests, and I don't have a problem with that. Even if it doesn't eliminate all the bugs, I can imagine it is a much nicer way to go than writing it all and giving it to someone else, while saying "Good Luck!" Furthermore, you now know, if you make a change, if it breaks anything. That is much better than making a fix and giving it back to the tester hoping they find whatever you broke. So, I agree with you that there should be someone else who is responsible for writing acceptance tests; however, I think the developer should write unit tests so that grace need not abound.