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
  • Antipatterns
  • 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.