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:
- Write a test, verify it fails
- Implement the production code
- Run the test again, verify it passes
- Run the whole spec file, verify all tests pass
- 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.
