I was first introduced to the idea of unit testing when I read an article by Kent Beck and Erich Gamma called Test-Infected: Programmers Love Writing Tests in the late 1990s. I didn’t start practicing it immediately, but as I learned about Extreme Progamming (XP), I started doing test-driven development (TDD) and have been ever since.
Over the years, I’ve learned a lot about writing good tests, mostly by writing bad ones and dealing with the consequences. I’m still learning, but I’ve developed some thoughts and opinions on the subject.
As I read and study more, my approach to testing evolves. I’ve made a major shift in how I test over the past few years as a result of reading some good books and articles and then trying out the ideas I found there.
This post begins a series where I’ll talk about writing good tests. A lot of my testing habits are so ingrained that I don’t even notice them any more. Over the past few months, I’ve been paying closer attention to what I’m doing and why. I’ve tried to surface those habits so that I could capture them in this series.
While this list will probably evolve as I go, I currently plan to cover:
- Mechanics of testing
- My testing philosophy
- Writing clear tests
- Writing flexible tests
- Letting tests drive design
- Dealing with legacy code
- Other kinds of tests
Why am I calling this series “Getting Testy?” In my work, I often run into tests that are just painful to work with (often ones written by a younger me) and they make me cranky. “Testy” is a synonym for “cranky” and I like the play on words.
I expect that you’ll agree with some of the things I say and disagree with others. That’s great! But I hope that I’m able to make you think about the tests you write, and that you end up writing better tests as a result.
I hope you enjoy the series and find it useful.