Re:TDD: tastes better without the T?
by terra_t on Wednesday April 28, 2010 @12:20PM
(#1301912)
My use of tests is situational.
If I'm writing security-sensitive string parsing code that isn't going to change much, I'm going to write a thorough set of unit tests.
When I wrote database abstraction layer that ran on MySQL, PostgreSQL, Microsoft SQL Server and Oracle, I found that a good set of tests made the process of porting the system to a new database almost trivial.
Back when I was getting my PhD, I rewrote a simple-but-slow calculation to use a fast-but-complicated-as-hell algorithm, and I don't think it would have been possible (to get the right answer) if I hadn't used the simple code to create unit tests for the complicated code.
On the other hand, there are a lot of cases where I've written unit tests and they've become a liability over time; for instance, requirements would change, so I'd have to go back and maintain this collection of tests that, frankly, I didn't care about anymore.
If I'm writing security-sensitive string parsing code that isn't going to change much, I'm going to write a thorough set of unit tests.
When I wrote database abstraction layer that ran on MySQL, PostgreSQL, Microsoft SQL Server and Oracle, I found that a good set of tests made the process of porting the system to a new database almost trivial.
Back when I was getting my PhD, I rewrote a simple-but-slow calculation to use a fast-but-complicated-as-hell algorithm, and I don't think it would have been possible (to get the right answer) if I hadn't used the simple code to create unit tests for the complicated code.
On the other hand, there are a lot of cases where I've written unit tests and they've become a liability over time; for instance, requirements would change, so I'd have to go back and maintain this collection of tests that, frankly, I didn't care about anymore.