So you want to try test-driven development (TDD) — great! But that requires expressing the intent of the code-to-be in automated tests. Where should you start if you don’t even know what the code should do? What should you do if you’re not confident about a particular approach?
You drive a spike through it!
To start my “Marvel Browser” iOS TDD sample app, I want to begin by making a network call to the Marvel API. If I knew what I was doing, I would start the 3-step “TDD waltz” of writing a single failing test, then writing the simplest code that passes, then refactoring.
But there are two roadblocks keeping me from writing my first test:
- It’s been a while since I wrote an NSURLSession call. What does it need? How does it call me back? I want to write tests that simulate the various ways the framework can call my code, including error conditions. But I don’t quite remember the flow of control.
- In order to call the Marvel API, I need to satisfy their authentication requirements. There’s some process of signing requests with an MD5 hash. I’m afraid if I try TDDing my way there, I’ll end up with something that “looks right to me” but doesn’t actually work end-to-end.
When you’re dealing with an unfamiliar framework call, or an unfamiliar sequence of calls that needs to work end-to-end, TDD is not the place to start. Instead, you need a “spike solution.”
What’s a spike solution?
A spike solution is a code experiment. It’s called a “spike” because instead of carefully building things up layer by layer, we just brute-force something, driving through multiple layers.
A spike solution is dirty & quick. Don’t spend time making it right. Instead, code just enough to get the answer you need.
Sometimes you can create a spike in a brand-new, throwaway project. But often, I find it easier to use my project’s existing infrastructure to set up the scenario I need. In that case, put the spike in a branch.
Throw it away when you’re done with it
You can tinker with your spike, hacking any way you please. You can study what you come up with. But you must resist the temptation to start copying the hack over to your production code. Resist!
In fact, once you’re done with a spike solution, throw it away. There are good reasons to do this:
- It frees you from any constraints to write clean code while you’re experimenting. Quick & dirty is the name of the game. Just hack.
- It avoids creating production code not covered by unit tests. Once we have the answers we need from our spike, we can start the TDD cycle back in the real code, using what we learned.
- It keeps you from writing tests that merely mimic the spiked code. As you build up tests and refactor, the production code may assume a radically different shape from the spike solution.
Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.
Here’s how The Art of Agile Development by James Share and Shane Warden answers the question, “Should we really throw away the code from our spikes?”
Unless you think someone will refer to it later, toss it. Remember, the purpose of a spike solution is to give you the information and experience to know how to solve a problem, not to produce the code that solves it.
Let’s spike a call to the Marvel Comics API
As I explained in TDD Sample App: 20 Topics that May Spill Out, the main thing I want the Marvel Browser to do is send a name prefix and get back comic book characters. Again, there are two things I’m uncertain about: how the NSURLSession works, and how Marvel does request authentication. So let’s spike it in part two: Spike Solutions: 7 Techniques You Can Use.
When have you used spike solutions? Did you throw them away? You can leave a comment by clicking here.