In "TDD as the crack cocaine of software", Jef Claes talks about the way that TDD (with really fast tests) can create the preconditions for Flow. Flow is emotionally rewarding, so that becomes its own reason to write tests this way, in addition to the desirable outcomes of catching bugs and informing design.
Other psychological (not technical) reasons to do TDD or other types of testing:
- Confidence.
Knowing that I have tests makes me feel safe that I can make changes and ship working software.
Note that this confidence may be false! For example, if I base that confidence on reported code coverage, even though code coverage often does not correlate with quality. (Even worse, if I ignore other quality-ensuring activities because I focus my attention on code coverage, my quality will suffer while my confidence increases.) It's very tempting to celebrate coverage numbers. Don't do it.
Interestingly, following The Three Rules of TDD will tend to result in very high coverage and good quality.
- Incrementalism
TDD with a tiny Red/Green/Refactor cycle helps you take small steps. You get the feeling of making progress all that time. You're always a minute or so away from a reverting to a green bar.
- Tracking progress/status
If I get interrupted, I can look at my most recent unit tests to remind myself what I was doing. I can write my next failing test as a note to my future self about what I wanted to do next. (While I'm away, I'll probably change my mind, but the note is still valuable.)
Also, if I commit each passing test, another programmer can read the history to see the path I took. But I'm getting off topic for this post.
Maybe you can think of more examples, or a better way to organize these ideas - let me know!
No comments:
Post a Comment