So, for me, TDD is about minimizing my own fallibility. Many of the functions for which I write tests are never exposed in an API. (Yes, really.) This helps me to pinpoint places where I've screwed up, by showing me places where I haven't screwed up; if something bar() does is based on the result of foo(), and I can demonstrate to my own satisfaction that foo() is behaving properly, then if bar() is misbehaving then that's one less thing I have to check. Assuming I wrote my tests correctly.
I know where I tend to get lazy in areas that may end up biting me later, and I think this approach will help lessen my laziness in such a way that I'm more productive with the lines of code I write. YMMV.
Note that most of what I write are either scientific libraries or user-facing applications.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2009-05-29 04:33 am (UTC)I know where I tend to get lazy in areas that may end up biting me later, and I think this approach will help lessen my laziness in such a way that I'm more productive with the lines of code I write. YMMV.
Note that most of what I write are either scientific libraries or user-facing applications.