If you’re like me you prefer RSpec to the Test::Unit (the default testing framework that comes with Rails by default). You immediately kill off the “test” folder in your app and bootstrap RSpec with “./script/generate rspec”. When you run the default rake command (’rake’) in the root of your app you are greeted with the following:
OMG - WHAT IS THIS CRAP IN MY CONSOLE?
I know these don’t come with RSpec because ‘rake spec’ is silent (because we don’t have any specs yet — which is fine, we’ll build them later, don’t worry). This little thing has annoyed me for a while now but I’ve just had more important things to do instead of digging in and figuring out where this output is being generated, you know, like client work, the stuff that pays the bills.
Today, I took the time to figure it out and it was crazy simple. I’m kicking myself for not checking it out sooner (I feel like such a dirty noob *shakes head*). It turns out that each one of these blank lines represents one level in Test::Unit - unit, functional, and integration. Since I delete the “test” folder on sight (in new projects using RSpec) there aren’t any tests to run and this is actually part of the default output each Test::Unit run.
Now that we have an understanding of what’s going on here — we have to dig in a little more and figure out where this rake task is being defined. Since Test::Unit is being fired off when we call a ‘rake’ by itself it means that there is a default rake task (’task :default => :sometask’) specified somewhere that is causing this behavior. Another thing I tend to do in my applications is freezing Rails so I don’t have to depend on the version of Rails lives on each machine on which this app is hanging out. This allows me to search through the Rake tasks that come with Rails by default. A good portion of these tasks live in ‘railties’ (general framework utilities) so we can start our search there (in ‘vendor/rails/railties/lib/tasks’ - because ‘lib/tasks’ is where Rake tasks tend to live). In order to search for ‘:default’ within Railties we’ll bust out our trusty friend ‘grep’:
That grep command says: search inside all files ‘-R’ found in ‘vendor/rails/railties/lib/tasks’ for any line containing ‘:default’ and show the line number ‘-n’.
BINGO! There it is! All you need to do is edit ‘vendor/rails/railties/lib/tasks/misc.rake’ and comment out line number one. Then if you run the default rake command ‘rake’ (by itself) you should no longer have to endure the filthy remnants of the Test::Unit.
Recently I began the migration back to Vim for my day-to-day text crunching needs. Textmate is good but it’s starting to feel like abandonware; who knows when Textmate 2 is going to be released or if it even exists. It’s future feels uncertain. I need certainty. Anyway. Not what I want to talk about.
I want to talk about RSpec syntax highlighing in Vim or my apparent lack thereof. Check it out:
Missing RSpec keyword syntax highlighting
I’m using MacVim with the vim-ruby gem installed. There has to be an easy way to get RSpec syntax highlighting for all the RSpec keywords although I couldn’t fine one after spending time scouring the Google. Time to break out the ‘Hard Way’.
That SEXY theme you see is a modified port of the TextMate theme called Monokai. It’s was originally ported to Vim by Thomas Restrepo. Monokai forms a solid basis for some supurb eye candy but my taste requires a bit more flare.
It was a pain to figure out how to tag things with the proper colors when working on a new vim color file. After quite a bit of initial pain I found SyntaxAttr.vim and it made my Vim themeing life quite a bit more enjoyable. SyntaxAttr will tell you the exact syntax highlighting attribute Vim is using to attach a color to an element. In the case of RSpec ‘description’ and ‘it’ keywords Vim was telling me: “<no syntax group here>”. Bummer.
Now we have to go in and force Vim to recognize these keywords as syntax so we can hang colors off of them. You can do this using ‘after’ syntax files. This will allow you to add to an existing syntax file without modifying the original. You can see a more detailed explanation of this in the Vim documentation for syntax files.
I chose to override the ruby.vim syntax file. I did this by creating a blank ruby.vim syntax file in ~/.vim/after/syntax/. You may need to make the after and syntax directories if they don’t already exist. This is what I put into my ruby.vim override file:
UPDATE: This code from Tim Pope (via Josh Nichols in the comment) is better as it will only apply this formatting for ‘_spec.rb’ files. Thanks Josh!
This is just standard syntax file stuff: the first two lines are searching for matches and the next two lines are assigning them to an existing syntax structure.
(If you don’t want to piggy-back on an existing syntax definition [as I've done here] you can take a look at your theme in ~/.vim/colors for the proper way to add a new definition. Instead of specifying “Define” you would specify your new definition.)
The override ruby.vim finds lines starting with “describe” and “it” and assigns them to the “Define” syntax definition. In Monokai Modified this is HOT PINK (as it should be):
