Though I realize their limitations, I do like mock objects
a great deal. (Watch for an article on them soon.) My rules of thumb are:
- Decouple the code as much as possible. (avoid the issue)
- Assume a baseline of working behavior. (I'm pretty sure Perl works, and I can avoid a few places where it doesn't.)
- Run smoke tests.
- Run integration tests.
- Use testing data.
I'm convinced there's a way to mark dependencies in the unit tests (though moving to a contract-based programming model is probably a better answer). I just don't quite see it yet -- unless you can mark a dependency on a test name in another unit's tests. Then you'll need graph traversal and tracking... but it's an idea.