We’re all agreed that any Python code that’s even a little serious needs unit tests, right? However, sometimes we end up writing our tests after we’ve written our code rather than doing test-driven development, what Curtis calls “code and cover”. That’s bad. Here’s why.
- It’s dull. Really dull.
- You find bugs, but it’s somehow more frustrating. Perhaps because you thought your code was correct already.
- The code is probably not written for testability, which means you have to mix refactoring up with verifying behaviour. Messy & perilous.
- Alternatively, you write tests with a lot of mocks. Not bad in itself, but risky.
- It’s much harder to get full coverage.
- You write tests for things that you don’t care about, just to exercise a particular code path. This makes the tests more fragile.
- You never really know when you are finished.
Are you a TDDer or a code-and-cover person? Why do you prefer it that way?