This post comes from an internal collection of writings on testing and software design. It assumes you like the idea of automated testing in theory, but have not found it doable in practice. This and future posts hope to provide you with approaches to testing and software design that will make automated testing both practicable and approachable.

Automated testing is the software equivalent of eating your vegetables. You could, you should, but… eh, maybe next time. But then “next time” never comes around. Finding the perfect time to take that first step into testing seems a challenge best avoided, especially when you don’t really know what awaits.

Good news: I’ve found the perfect “next time,” and you’re probably going to have a few opportunities to level up your testing skills today.

But first, let’s clear up confusion about what it takes to improve your skills in testing.

So Many Skills

Learning to use tests as a development tool requires mastering a variety of skills:

• Basic mechanics
  • Using your test framework to write tests
  • Using your build system to run tests
• Strategic decision making
  • Deciding what to test and how
  • Deciding what to test first
• Software design judgment
  • Understanding how to break something down into small, easily testable parts
  • Understanding how to reshape something that’s not testable into something that is

There is plenty of extant literature on software design, ranging from the venerable Gang of Four phonebook to blog posts extolling the pattern du jour.

But before you can begin to worry about translating test feedback (“this is hard to test”) into architectural changes (“so let’s bud off a focused class”), you have to know how to write tests. You have to get a handle on basic test framework mechanics and less-basic strategic testing decisions. This requires getting a leg up on the difficult, test-specific challenges of how and what to test—and hey, how does this test thing even work, anyway?

So Little Time

Trying to master those test-specific skills while remaining productive on the job is a real challenge. “I’ll just take a couple weeks to figure out this testing thing” won’t fly at most jobs, and you probably wouldn’t be too happy about it, either. The last thing we need is testing that acts as a lead weight on our work process.

Bugs Are Already-Written Tests

This is where debugging comes in: The “what to test” decision has already been made:

• You have a focused issue.
• You have steps to reproduce.
• You know what it’s supposed to do.

This provides the perfect scenario for you to practice using the test framework and test runner—not as a blocker to work, but as a means to more quickly accomplish work.

As you continue to turn to tests as a tool for debugging, your comfort and familiarity with your testing toolkit will grow. You’ll become a more effective debugger and a more effective tester.

From Debugger to TDDer

Eventually, you might approach new feature development as just another test-driven debugging session: the app is (now) supposed to do XYZ, but it doesn’t! such bug, very testable With that shift in perception, you’re suddenly doing test-driven development (TDD).

But you don’t start there: You get there bug by bug. Debugging through tests is an important first step along the path to mastering testing and software design, and it’s one you can afford to take in the context of your daily work.

Don’t Go It Alone

In future posts, we will provide you with approaches to testing and software design to help you develop more efficiently.

Is your organization interested in improving its testing? Big Nerd Ranch can help with that!