Alternate thought, I am finding it kind of strange that the spec dir does not mirror the implementation and I am wondering if splitting based on rspec vs JS vs no runner makes sense.

I am leaning towards combining into a single spec file at `spec/plugin/spec_runner_spec.rb` with the following structure: 

``` ruby
# spec/plugin/spec_runner_spec.rb (admitedly weird name, but mirrors dir structure)

describe 'Vim Spec Runner' do
  context 'configuration' do
    it 'uses the command executor override if present'
  end

  context 'runner' do
    context 'none identified' do
      it 'does not run the spec command'
      it 'alerts the user that it could not run the command'
    end

    context 'an rspec file' do
      it 'uses rspec as the runner'
    end

    context 'a js file' do
      xit 'uses konacha if found'
      xit 'uses teaspoon if found'
      xit 'uses jasmine if found'
    end

  end

  context 'preloader' do
    it 'uses "zeus" when a zeus.json file is present'
    it 'is "spring" when spring-commands-rspec is in the Gemfile.lock'
    xit 'uses no preloader when running js specs'
  end

  context 'path' do
    it 'is the path to the spec file'
  end

  context 'focus' do
    it 'appends the current line number to the path for an rspec file'
    xit 'runs the full spec file for js'
  end
end
```

We could still extract helper functions into support to clean up / simplify the spec file if we wanted, but since we don't expect this to grow too much beyond its current size, I am in favor of having all in a single spec file. @gabebw thoughts?