Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
Zequez opened this Issue · 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
Collaborator

@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
Collaborator

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

@thibaudgg
Owner

@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
Owner

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
Owner

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.