Is running just specific parts of an spec file a bug or a feature of the v4? #231

Closed
Zequez opened this Issue Dec 19, 2013 · 9 comments

5 participants

@Zequez

When I start guard with guard-rspec 4+, the first time I save an spec (specifically a model spec, but I haven't tried others), it runs all the specs in the file. Then I just made a modification, to the file, like adding a white space, and it runs only some of the specs of the file.

I tried with v4.2, v4.1 and v4.0, and all did the same thing. But when I downgraded to v3.1 the problem was gone, it ran all my specs of the same file.

When I watch the debug log, the first time I run it it says:

02:22:47 - INFO - Running: spec/models/game_spec.rb

But when I modify the file, it logs:

02:22:54 - INFO - Running: ./spec/models/game_spec.rb:14 ./spec/models/game_spec.rb:19
Run options: include {:locations=>{"./spec/models/game_spec.rb"=>[14, 19]}}

So, somehow it's deciding it only has to run the tests in line 14 and 19, and I have much more tests than those two in that file.

If it's a feature (I don't see how), an instruction of how to disable it would be nice. And if it's a bug, and you don't know what might be causing it, I will gladly provide you with a sample app to reproduce it.

@907th
Guard member

@Zequez Are the specs at lines 14 and 19 passing succesfully?

@Zequez

@907th not necessarily, I can change it to fail or to pass, and it shows the same behavior. I think it's trying to detect if I modify certain parts of the files somehow, and run only the affected tests. But it should still run ALL tests when I change a file that is not an spec. Anyway, the behavior is rather unpredictable, I can't determine what triggers it yet, sometimes it runs all specs and sometimes just a few. It really never happened to anyone before? Isn't any feature that could be related?

@907th
Guard member

@Zequez sounds like there is a bug. Please, provide a sample application.

@thibaudgg
Guard member

@Zequez Yep it's anormal, that's for sure. A sample application would greatly help, thanks!

@bensheldon

Is there a way to disable this?

I'm having the same issue with a project I unfortunately can't share (it seems to be cause by my use of rspec macros. e.g.:

RSpec.configure do |config|
  # adds a #check_collect method
  config.extend ShirtVendorMacros,
    :type => :shirt_vendor,
    :example_group => { :file_path => %r(spec/shirt_vendors) } 

Those macros are called within a spec file:

require 'spec_helper'

describe Goodjoe do
  check_collect :collect
end

When I modify and save the spec file, I get this:

21:14:28 - INFO - Running: ./spec/support/shirt_vendor_macros.rb:44 ./spec/support/shirt_vendor_macros.rb:49
Run options: include {:locations=>{"./spec/support/shirt_vendor_macros.rb"=>[44, 49]}}

All examples were filtered out

Finished in 0.00022 seconds
0 examples, 0 failures

It seems like it fails the first time, but if I resave the file a second time, it works. I can try to put together a sample app, but is there a way to disable this in the meantime?

@bensheldon

Question: is this related to the failed_mode in the configuration options (default is :focus)? It seems like using this fixes it:

guard :rspec, cmd: 'bundle exec rspec', failed_mode: :none do
  # ...
end 
@thibaudgg
Guard member

Yeah the (default) :focus mode will keep the line number that failed, use failed_mode: :none if you don't want it.

@samcdavid

I don't know if this will help anyone, mainly because I'm a noob, but adding failled_mode: :none did fix a rather peculiar problem that I was having.

In my new rails application, whenever I modified a model (or its corresponding spec) guard would only execute the first test that ran after that instance of guard was started. For example, if I started guard using bundle exec guard and then made a change to my users model the users spec would run as expected. However, if I then made a change to my requests model, guard would only execute the user spec.

I don't know if the behavior I described above is desired, but I wanted to share in case another noob ran into this problem and got stuck.

@thibaudgg
Guard member

@samcdavid yep it's the default behaviour of failed_mode described here: https://github.com/guard/guard-rspec#list-of-available-options

@thibaudgg thibaudgg closed this Apr 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment