Developmentastic

  1. Using Slime To Execute Cucumber Features

    I learned of the wonders of slime from David Whittington during his CPOSC talk on Clojure. He would write a line of code and, with a single keystroke, it would be whisked away and executed in a terminal window. This proved especially useful in his demonstration because he was able to write and manipulate blocks of code in vim and have it execute in the REPL. I tried it for myself when playing with Ruby and lisp to found it far more productive than monkeying around at the command line.

    You can get up and running with slime.vim in a few minutes. Jonathan Palardy wrote a detailed tutorial describing slime’s merits, his setup, and how to use it with irb. Absolutely worth a quick read.

    I’ve been meaning to find a decent solution to execute my tests from within vim instead of having to constantly switch between it and a terminal. I came across a post by Paul Battley outlining his solution using autocmd to define a few simple mappings any time a Ruby test file or Cucumber feature is opened. He’s updated the script since writing that post, so be sure to check out the living copy on GitHub. I spend a great deal of time writing Cucumber features so anything that makes executing them less painful gets my attention.

    I’m sure it’s obvious where I’m going with this. Using slime.vim, the opened feature or focused scenario can be sent to a terminal window to run in the background instead of running in the foreground of vim. Here’s what I ended up with:

    augroup Cucumber
  au!
  autocmd BufNewFile,BufReadPost,BufEnter *.feature,*.story
    \ set filetype=cucumber|
    \ :nmap <leader>r :call Send_to_Screen("cucumber -r features " . expand("%") . "\n")<CR>|
    \ :nmap <leader>R :call Send_to_Screen("cucumber -r features " . expand("%") . "\:<C-R>=line(".")<CR>\n")<CR>|
augroup END

    When editing the file features/account.feature, the mapping ,r (assuming comma is your leader) will send the command cucumber -r features features/account.feature to the screen session. ,R functions similar but appends the current line number so only the scenario your cursor is on will be executed.

    After using these mappings for a few minutes, I realized many times I’m inside a step definition or somewhere else outside of the feature and want to re-run the last scenario. A simple mapping to execute !! is all you need.

    :nmap <leader>l :call Send_to_Screen("!!\n")<CR>

    A sample workflow looks something like this:

    1. Setup a screen session as Paul describes.
    2. Open a feature and write a scenario.
    3. Mash ,R to run it.
    4. Tell slime.vim the names of your session and window.
    5. Watch it fail.
    6. Implement each step one-by-one and use ,l liberally to re-run the scenario.
    7. Commit.
    8. Rejoice.
    9. Repeat.

    Some things worth mentioning:

    • I tweaked slime.vim to default the session and window names to “s0” and “w0” respectively.
    • Only using screen a handful of times, it threw me off that it has its own scrollback. It makes sense, but I only run one session per terminal tab so I don’t mind disabling that feature.
    • It’s also nice to default the window title to the same value configured in slime.vim.

    Here are the relevant lines from my ~/.screenrc:

    termcapinfo xterm* ti@:te@
shelltitle 'w0'

    And an alias I threw into ~/.bashrc:

    alias s="screen -S s0"

    I’ll definitely be expanding these tools to better fit my workflow. If you have a clever addition or another approach to the problem, I’d love to see it.

    Update: I’ve been advised to clarify one point. slim.vim isn’t technically slime; it’s just a way to get some similar functionality in vim. Thanks, David, for pointing that out before the angry tweets started streaming in from emacs users.