The #1 Thing Your Bootcamp Didn't Teach You

A while back I sent out a survey and conducted interviews to find out what questions my readers had about testing. Wow, were the results illuminating!

Two clear themes emerged: People want to know How to Start and What to Test. These came up again and again as I talked to you all, and they are results of the same root cause:

Your bootcamp didn’t teach you to write testable code.

Testable code is the foundational piece you’re missing and your bootcamp didn’t teach it to you. This is not a dig at bootcamps. As you surely know, I was a bootcamp instructor myself. Testable code is what allows you to build resilient, complex systems, instead of brittle, bug-ridden ones. Companies whose engineers aren’t testing their code either aren’t doing anything very interesting, or they’re doing it badly.

Sure, you can find jobs at companies that don’t test their code. But as you advance in your career and your understanding of software development, the brittle systems built by untestable code are going to keep dragging you down into bugfixes and maintenance headaches. Wouldn’t you rather be building new things and solving interesting problems instead of fielding tickets from the product department about user-facing issues?

Your bootcamp may have done a day or two on testing, and maybe you’ve tried to teach yourself a bit. I’d be willing to bet you found the whole experience maddening.

Testable code makes testing easier, and good tests make it easier to write more testable code. It’s a virtuous cycle, but if you don’t know where to start it becomes a chicken-and-egg problem.

So starting this week I’ll show you how to approach the code that you write with a testing mindset and clarify what the tests should actually look like.

To get you in the headspace, try this exercise. In my next article I’ll go over it.

An Exercise

Pick a non-trivial piece of code that you understand well. It doesn’t have to be something that you’ve written yourself, but you should be very familiar with it. It should have clear boundaries, maybe the size of a class or a small module. Describe three things about it, in this order:

What is its responsibility? Why does it exist? What task or entity does it represent? What actions does it perform? Is that responsibility clearly defined, or diffuse?

What is its abstraction? What mental model and methods does it present to you for use?

What is its behavior? What concrete, observable effects does it have that tell you if it’s working correctly?

To build resilient and maintainable (ie. testable) systems, you should be able to answer these questions about the system as a whole and its constituent parts. Stay tuned for a demonstration in my next article.

Next Up:
If You Can't Test It, You Need to Rethink It

Previously:
Building a Banjo - A Coding Exercise