An Improved vim-rspec Workflow

Chris Thorn

Nearly two years ago we announced our vim-rspec project, a tool for running RSpec tests from within Vim. It allows for a workflow that fosters a tight TDD loop, minimizing development downtime.

A typical TDD workflow

When implementing a new feature, my typical TDD loop looks like this:

  1. Write a test, verify it fails
  2. Implement the production code
  3. Run the test again, verify it passes
  4. Run the whole spec file, verify all tests pass
  5. Repeat

After running through this loop several times, I’ll stop to run the whole test suite.

vim-rspec lends itself well to this workflow, by exposing the functions RunNearestSpec() to run the spec nearest to the current line, and RunCurrentSpecFile() to run all tests in the file. If the active buffer is not a spec file, these functions will run the last executed spec.

In thoughtbot/dotfiles, we map <leader>s to RunNearestSpec() and <leader>t to RunCurrentSpecFile() to make them easy to execute.

A pain point

By only storing a single last spec execution, RunNearestSpec() and RunCurrentSpecFile() will do the same thing when the active buffer is not a spec file.

If I’m implementing a new feature, it’s easy to run the last spec for it by entering <leader>s. But when that single spec passes, I have to open the spec file in the active buffer in order for <leader>t to execute the whole thing. This extra step hurts my TDD loop.

An improvement

Recently, we updated vim-rspec so that RunNearestSpec() and RunCurrentSpecFile() track their last executions separately. Now when the active buffer is not a spec file, <leader>s will execute the last nearest spec and <leader>t will run all of the specs in the last executed spec file.

A speed bump has been removed from my workflow, and my TDD loop is tighter than ever.