USE TDD FOR FASTER DEVELOPMENT

Every engineer *knows* they should be adding tests to their work, but most of us, it’s one of those things that gets “cut for time.”

If you’re on any sort of deadline (which, yeah) then this pressure is totally understandable. You don’t get more points from the customer for writing tests to make sure something works. They only care if it works!.

The usual argument says adding tests is a way to prevent future problems. Spot on. However, there’s another reason you should be writing tests that pay off now instead of in the future.

Writing tests before you start helps you work faster than writing no tests at all.

WHAT IS TEST-DRIVEN DEVELOPMENT?

Test-driven development, or TDD, is the process of writing a series of tests for your code to pass before you’ve even written the code.

It goes like this:

1. Write out tests your code needs to pass
2. Code your function/page/API
3. Test
4. If it passes, move on; if not, go back a step
5. Then, look at your next test
6. Add or alter your code to accommodate it (if it doesn’t pass already)
7. Test again
8. Repeat until all tests pass

In contrast, here’s the “process” that most of us follow if left to our own devices:

1. Build a function
2. Run your program
3. Does it work? Cool. Maybe you try it a few more times, throw in a null value or something as a kind of “QA-lite.” But it’s not a standard, it’s more of a “oh yeah, let’s add that.”
4. Ship it.

At a glance, the first path looks more tedious. Why do 8 steps when you can do 4? That’s just common sense!

However, while it looks like the TDD path takes more time than business-as-usual, it’s generally the opposite. TDD gives you clarity in your direction, a way to measure success, and a final, “shippable” point (the passing of all predefined tests) that prevents scope creep.

AN EXAMPLE? SURE.

You are developing an API. Your API will be a GET request taking in a user’s ID and authentication token and will return the 10 latest photos from their profile. It will also record the time and date of the request to a database.

Right off the bat, there are a handful of error conditions I can think of:

1. Request is made without user ID
2. Request is made without authentication token
3. Request is made with the wrong auth token
4. The request is fine, but the photos can’t be found (DB error)
5. The request and retrieval work, but there was an error writing the event to your query-history DB
6. The user doesn’t have 10 photos to retrieve

These are fairly obvious needs to handle, yet if one doesn’t take the time to write them out ahead of time, it would be incredibly easy to overlook these in your development process. This is a problem because your QA or PM will catch these and send your work back to you. It will take twice as long to “fix” the problem than it will be to develop it in a test-driven manner from the get-go.

HOW TO MAKE FRIENDS AND INFLUENCE (QA) PEOPLE

If you have a QA team, ask them for the 10 most common checks they typically apply to your code (or your team’s code). Write tests for the checks (or get close).

Better yet, ask them for the 10 most common errors they find in pre-shipped code. Write tests for those, and become their favorite engineer. Now that you’re their favorite engineer, you may find that your code gets priority when there are eight different PRs out for them to review because they know yours will be the least headache.

BE A TEAM PLAYER

Create a basic template for you and your team to use, a simple file you can copy and paste and run your code through. For every new function, page, endpoints, etc. you now have a rough set of criteria it needs to pass in order to even get a PR made (based on what you learned from your QA folks). This doesn’t have to be a hard-and-fast rule, just something to serve your team in the process of development.

If your team doesn’t have a culture of testing, you may find it hard to make that shift. A framework like TDD makes their work faster and easier, and it’s hard to say no to that.

WHAT IF MY TEAM DOESN’T HAVE QA OR CODING STANDARDS?

Then it’s time to create some. Start now, even if it means starting badly. Or contract a QA for a month to look over your shoulder, learn your product, and ask the insightful questions you’re missing, then translate those questions into tests so you can make TDD a part of your workflow.

THE LAST WORD

TDD is like sharpening the saw. It may not seem “productive,” so you may have a mental block about making time for it, but it absolutely makes up for the up-front cost by increasing your rate of productivity.

Deeter Cesler