Here’s the basic TDD workflow:

  1. Write a test
  2. Run the tests
  3. Write enough code to make it pass
  4. Run the tests
  5. Refactor the code
  6. Run the tests
  7. Repeat

Give or take that’s how it works. If you take a quick look at that list, you’re running the test suite after every change you make either in the code or the suite itself.

Even if you’re not doing TDD (maybe test first or test after), running the test suite is a recurring process.

Leaving the actual command aside for a moment, running the specs can be accomplished in many ways (workflow-wise)

  • Throw the editor to the background while the specs runs in the foreground (I’ve seen Gary Bernhardt do it this way)
  • Run them on a different terminal all together
  • Use guard or a similar tool
  • Use a cool Emacs tool
  • Something else

In this article I’ll share the way I do it

rspec-mode

In Emacs we have rspec-mode, a minor mode that allows us to run our specs without ever leaving the editor. There’s also minitest-mode if MiniTest is your weapon of choice and, as far as I tested them, they are compatible (meaning that they mostly accept the same or very similar keybindings and have similar features).

It provides a wide array of features worth mentioning. Here are some of the commands I normally use

Command Description Keybinding
rspec-verify-all Run the entire test suite C-c , a
rspec-verify Run the spec file associated with the current buffer C-c , v
rspec-verify-single Run the specs, describe or context under the cursor C-c , s
rspec-rerun Re-run the last command C-c , r
rspec-toggle-spec-and-target Toggle back and forth between a spec and its target file C-c , t

The first four commands will run the specified specs in a separate buffer without interfering with your workflow.

In that buffer, you can navigate the failures and by hitting enter (or clicking with the mouse) on the error location, it’ll jump to that place for you to see and/or modify the code.

You can also run some of this commands from within a dired buffer, but I don’t use them that often.

It also provides some configurations for using rake and bundler for running the specs if available.

More commands

While reading the code base (in order not to forget anything), I came across this commands I didn’t know and seam like a good choice to learn

Command Description Keybinding
rspec-yank-last-command Yank the last verification command to clipboard C-c , y
rspec-toggle-spec-and-target-find-example Toggle back and forth between a method and its examples in the spec file C-c , e
rspec-verify-matching Run all specs related to the current buffer C-c , m
rspec-verify-continue Run the current spec and all after it C-c , c
rspec-run-last-failed Re-run just the failed examples from the last run C-c , f

I’ll probably be trying them out in the near future.

Conclusion

I find rspec-mode very compelling, I use it all the time. Even if I’m not using RSpec, I tend to modify the running command instead of trying out other modes because I’m very used to it.

The only thing I find somewhat annoying are the keybindings, I find them too long for my taste and I haven’t dedicated the time to re-map them to some Hyper command. I’ll probably find a way at some point. For now, I hope you enjoy rspec-mode.

Saluti.