I’ve gone through a number of different tools to streamline and ease the running of tests in my applications. Until a few months ago I was firmly implanted in the auto test world with tools like Guard. Coming from a world where Mighty Moose and NCrunch were the power tools of choice, I found Guard was much more robust.
For as much as I’ve liked Guard, I’ve recently found myself frustrated at the brutish inaccuracy of the tests being run with any tool: guard, grunt watch, etc. None seemed to capture the context I was in, because that changes by the moment. In fact, a narrow test run succeeding as I close up a class’ new edge case can immediately trigger my curiosity of the entire class or suite.
I need an electron microscope in one moment and a wide-angle lense the next.
vim-rspec and tslime Weren’t Quite Right
My first iteration was using vim_rspec, augmented with the excellent suggestions of Thoughtbot for Tmux integration. This allowed me to send the current RSpec test, context, or file to my preferred Tmux pane always located at the bottom.
Things were peachy for a time, but nagging problems surfaced:
I tired of specifying which pane to run the tests after closing vim (which I do too often).
We have cukes in our test suite that require going au natural and losing ease of specificity.
I want to run other commands quickly like
rake db:migrateorrake jobs:workoff.
Zen Flow
A few weeks ago, I decided to clean things up a bit, landing on the following tools and commands:
Vimux
Vimux is opinionated, and it’s opinions match my own—we get along great! With few exceptions, I run an editor on top and a thin pane on bottom to Do Stuff™. Vimux doesn’t ask you where you want commands run; it just creates a 20% tall pane at the bottom. No questions asked.
Turbux
Turbux is similar to vim-rspec, but it uses FileType support to run the appropriate command in Rspec specs or Cucumber features. While I think it could be extended to support pluggable Filetype commands (think Coffeescript & jasmine), it covers my bases for the moment.
My TDD Workflow (for now)
With the editor running in the top Tmux pane, I’ll usually have vim up top with two vertical splits: spec on one side and component under test on the other.
After writing my new test, I hit s to run the spec under the cursor. No more questions about which Tmux window and pane to run tests—Vimux has my back.
I flush out the functionality and hit l to run the last command again. Regardless of the vim split I’m in, the last set of specs runs again.
Here I might refactor some code, running l regularly.
Once I’m comfortable, I’ll expand my focus to the entire component under test with t for all specs in the test file.
All green? Now just run the full suite of RSpec tests with a or go even more broad with a for all specs and all cukes.
Throwing other commands
I’m continually finding little commands I want more readily available. After creating a new migration, for instance, I want that thing invoked!
dmg to the rescue.
You can find my Turbux config, Vimux config, and Filetype specific mappings in my dotfiles. With each of these little tools talking harmoniously, I feel in total control of my development time. I’m no longer scrolling guard output buffers or touching files just to run certain specs.
It seems I’ve traded outsourced, ambiguous automation for simple, but specific control. For the moment, I’m happy with the choice, but who knows what the next (r)evolution might bring.
