Not sure what test to write next? Create a TODO list with pending specs
You know you can get started doing TDD by asking questions… but what if you have lots of questions? Where do you start? What do you do when asking one question makes you think of three other questions? And how do you turn these questions into tests that you can use to help you create software?
Here’s something simple you can do: create a TODO list! But not just any TODO list… you can create your TODO list directly in your tests, so that you don’t forget about them. Just create a TODO comment for every question you have, and turn the question into a statement:
1 2 3
# TODO: It shows the user's name ("Does it show the user's name?") # TODO: It emails the user ("Does it email the user?") # TODO: Records a new signup to the database ("Does it record new signups to the database?")
Or, if you’re using RSpec, you can use pending examples:
1 2 3 4 5
describe "A new user signing up" do it "shows the user's name on the page" it "emails the user" it "records a new signup to the database" end
And when you run the tests, RSpec will tell you the tests are pending, and print your TODO list in a readable form:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
$ rspec todo_spec.rb *** Pending: (Failures listed here are expected and do not affect your suite's status) 1) A new user signing up shows the user's name on the page # Not yet implemented # ./todo_spec.rb:2 2) A new user signing up emails the user # Not yet implemented # ./todo_spec.rb:3 3) A new user signing up records a new signup to the database # Not yet implemented # ./todo_spec.rb:4 Finished in 0.00035 seconds (files took 0.09389 seconds to load) 3 examples, 0 failures, 3 pending
Just write the test descriptions. Don’t write any code inside the tests (yet). That part can come after, once you’ve clarified your questions. Right now, you just want to answer the question, “What should the software do?” And the best way to do that is to break it down into even smaller questions.
Take your time on this. Keep reworking your pending specs until they make sense to you as a group. Keep reworking them until you have a good understanding of what you want the software to do.
And then when you’re ready, start the TDD process – one test at a time. Turn your first pending test into a failing test. Write the implementation code to make the test pass. Refactor :) And then move on to the next one.
Here’s a little story for you… years ago, I was pairing with David Chelimsky (the main guy behind RSpec for a long time). We were faced with this exact question – what tests do we need to write? I opened a new file to write down our TODO list. David looked at me and said, “Dude… pending specs.” He had just added them to RSpec earlier that week, and I thought he just wanted an excuse to use them. They turned out to be incredibly useful, and I still use this approach in my work today.