You have a flash of inspiration for a new program to write. You open your editor to start working on it, and hear a little voice in your head saying, “You know, you really should test your code…” Do you listen?
Here’s the short answer: do whatever the hell you want! If you’re coding just for fun, or to experiment with an idea, then of course you don’t have to write tests. But here’s a concept you’ll find useful, whether you’re coding for fun or professionally…
Friction is anything that discourages you from making progress
That voice you hear, telling you to write tests – it might be a sign of friction, depending on how you respond to it. If you respond with, “Oh yeah!” and start writing tests, then it was a helpful reminder. But if you respond by thinking, “I don’t wanna write tests!” and then close your editor… that’s friction.
Let’s say you respond a bit differently, and choose to happily hack away on your code without writing tests. Good for you! You add an if statement here, a loop there, maybe extract a method or two to keep things clean… but after a while, the code becomes complex enough that you don’t really want to make a change, because you’re afraid of breaking something – more friction. Had you written tests at the beginning, you might have avoided this… but here you are.
Look out for friction – and do something about it
The simplest thing you can do when you encounter friction is to move in the opposite direction. You feel some friction about writing tests, and simply choose not to write them. That’s perfectly valid! But as we saw, ignoring early friction can really be just pushing it out of the way, and it builds until you have no choice but to face it head on.
Another way to deal with friction is to reduce it. Write out your assumptions that are embedded in the friction. For example, when it comes to writing tests, you might assume you need to…
- Use RSpec
- Set up a
- Create a
- Move your code into a class
- Test every method individually
And sure, when a project is rolling along, you might end up with all that stuff… but right now, just look at all that friction! No wonder you don’t want to write tests! What if I told you that at least three of those steps aren’t necessary?
Reduce first-test friction in two easy steps
You can reduce the friction of setting up your test environment, and get started by writing tests, with two easy steps:
- Include your tests in the same file as your implementation
- Embed the implementation directly in the first test
Here’s an example:
# interest_spec.rb require "bigdecimal" describe "Calculating interest" do it "handles simple interest" do principal = 1_000 rate = BigDecimal.new("2.5") years = 5 interest = principal * (rate / 100) * years expect(interest).to eq(125) end end
By doing this, you have added only a few lines of boiler-plate: the
it calls, and the
expect statement. You haven’t changed the original code you were going to write at all. When you write your next test, you can just copy the first test and modify it. Now you have duplication! Which you can refactor away… and now you’re rolling along.
After a few steps working this way, you’ll naturally move your implementation code into a separate file (so you can see them side by side), and extract certain pieces of code into methods (so you can focus on them individually). In just a short while, you’ll notice that those assumptions you made – which originally caused friction and prevented you from making progress – have worked themselves out automatically.
The next time you experience friction when coding, pay attention to it… and then look for ways to reduce it, rather than avoiding it entirely. You’ll prevent the friction from building up and becoming unavoidable later on.