drapergeek
commented
11 years ago Can you post your spec_helper as well? I can't see why this issue would occur so I'm hoping that can provide some insight.
Closed damonatbrightroll closed 11 years ago
drapergeek
commented
11 years ago Can you post your spec_helper as well? I can't see why this issue would occur so I'm hoping that can provide some insight.
damonatbrightroll
commented
11 years ago require 'simplecov'
SimpleCov.start 'rails'
# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV['RAILS_ENV'] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'rspec/autorun'
require 'shoulda/matchers'
Dir[File.dirname(__FILE__) + "/spec_helpers/*.rb"].each {|file| require file }
# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }
DUMMY_ORG_ID = 12345
DUMMY_VALUE = 'some random string'
EMPTY_STRING = ''
RSpec.configure do |config|
# ## Mock Framework
#
# If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
#
# config.mock_with :mocha
# config.mock_with :flexmock
# config.mock_with :rr
config.mock_with :rspec
config.include(ControllerMacros, :type => :controller)
# Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
config.fixture_path = "#{::Rails.root}/spec/fixtures"
# If you're not using ActiveRecord, or you'd prefer not to run each of your
# examples within a transaction, remove the following line or assign false
# instead of true.
config.use_transactional_fixtures = true
# If true, the base class of anonymous controllers will be inferred
# automatically. This will be the default behavior in future versions of
# rspec-rails.
config.infer_base_class_for_anonymous_controllers = false
# FactoryGirl configuration:
config.include FactoryGirl::Syntax::Methods
# From https://makandracards.com/makandra/950-speed-up-rspec-by-deferring-garbage-collection
config.before(:all) do
DeferredGarbageCollection.start
end
config.after(:all) do
DeferredGarbageCollection.reconsider
end
# Sunspot configuration (mock session)
$original_sunspot_session = Sunspot.session
config.before do
Sunspot.session = Sunspot::Rails::StubSessionProxy.new($original_sunspot_session)
end
# Sunspot configuration: add ':solr => true' rspec metadata to allow example groups that use this metadata flag
# to use the original sunspot session
config.before :each, :solr => true do
Sunspot::Rails::Tester.start_original_sunspot_session
Sunspot.session = $original_sunspot_session
Sunspot.remove_all!
end
config.before(:suite) do
# From http://robots.thoughtbot.com/post/21719164760/factorygirl-3-2-so-awesome-it-needs-to-be-released
ActiveSupport::Notifications.subscribe('factory_girl.run_factory') do |name, start, finish, id, payload|
execution_time_in_seconds = finish - start
if execution_time_in_seconds >= 0.5
$stderr.puts "Slow factory: #{payload[:name]} using strategy #{payload[:strategy]}"
end
end
end
endHere is an entire spec file as well, if that helps. Line numbers of failing tests have changed somewhat from what I pasted above, but the checks are the same.
require 'spec_helper'
describe Activation do
let(:activation) { Activation.new(:line_item_id => 1, :msg_id => DUMMY_VALUE, :status => Activation::Status::PENDING) }
describe 'associations' do
it { should belong_to(:line_item) }
end
describe 'validations' do
it 'should be valid' do
activation.should be_valid
end
it { should validate_presence_of(:line_item_id) }
it { should validate_presence_of(:msg_id) }
it { should ensure_length_of(:msg_id).is_at_most(Activation::MAXIMUM_LENGTH_OF_MSG_ID) }
it { should ensure_inclusion_of(:status).in_array(Activation::Status.values) }
end
describe 'defaults' do
subject { activation }
its(:status) { should == Activation::Status::PENDING }
end
describe 'attributes' do
[:id, :line_item_id, :msg_id, :status, :errors_text, :warnings_text, :created_at,
:updated_at].each do |expected_attribute|
it { should respond_to(expected_attribute) }
end
end
end@damonatbrightroll - can you send me an email : draper-at-thoughtbot-dot-com
thibaudgg
commented
11 years ago We also get this issue on the Semaphore CI, have you been able to fix it? Thanks!
damonatbrightroll
commented
11 years ago No luck as yet. @drapergeek had two suggestions for us:
The former had no effect. The latter immediately broke the build in environments that had otherwise been working. Continuing to investigate, but for now we are disabling all shoulda-related specs until we can resolve this.
damonatbrightroll
commented
11 years ago @thibaudgg Can you please post your files as I did above so we can compare notes? If you can also paste the platform(s) on which you're building, that would be useful as well.
thibaudgg
commented
11 years ago Removing the branch and re-adding it seems to have done the trick on Semaphore CI.
@damonatbrightroll We doesn't do anything special in our config, we just have gem 'shoulda-watcher in your Gemfile in test group.
damonatbrightroll
commented
11 years ago @thibaudgg What do you mean by "removing the branch and re-adding it?" In git or something else?
thibaudgg
commented
11 years ago @damonatbrightroll it's a feature of Semaphore CI, not in GIt.
davidjoliver
commented
11 years ago I'm using Jenkins and I'm seeing this as well. @damonatbrightroll any word yet? @thibaudgg I wonder if there is an equivalent...measure one can take within Jenkins...(?)
damonatbrightroll
commented
11 years ago @davidjoliver: No progress yet, unfortunately. Various shoulda tests remain commented out or replaced with (more verbose) vanilla RSpec for now, particularly should have_many, should have_one, should belong_to, should ensure_inclusion_of, should ensure_length_of, should accept_nested_attributes_for, should validate_presence_of, should validate_uniqueness_of, and possibly one or two others I'm forgetting offhand.
markoa
commented
11 years ago Just to clarify what @thibaudgg mentioned - removing the branch and re-adding it on Semaphore technically means that a repo (together with the cached bundle) is deleted and cloned again. So I think there's some randomness going on.
drapergeek
commented
11 years ago Unfortunately I have not been able to replicate this. If possible I would like to see someone create a bare bones project to replicate this issue. If a failure could be seem without using CI that would also be helpful even if we have to be specific about the OS and setup. Without being able to duplicate the issue my hands are somewhat tied at the moment.
damonatbrightroll
commented
11 years ago I am on vacation this week but will take a stab at it next week.
damonatbrightroll
commented
11 years ago I've tried but haven't been able to create a barebones project that demonstrates the bad behavior on my MBP. Anyone else able to do so?
cade
commented
11 years ago I just ran into this issue yesterday, so I was determined to figure out what was going on. I'm not sure if the root cause of your problem is the same as mine, but I was able to create a bare bones project that replicates the issue: https://github.com/cade/shoulda-matchers-goes-boom
Instructions are in the README for how to reproduce and artificially 'fix' the problem. Hope this helps.
damonatbrightroll
commented
11 years ago Thanks, @cade!
damonatbrightroll
commented
11 years ago @drapergeek Any progress?
kevTheDev
commented
11 years ago +1 for any progress?
damonatbrightroll
commented
11 years ago Post-Thanksgiving bump.
plribeiro3000
commented
11 years ago I had this same problem a while ago on a rack project. I solved it by stoping loading shoulda-matchers at Gemfile and loading it inside spec_helper.rb
Gemfile
gem 'shoulda-matchers', :require => falsespec_helper.rb
require 'shoulda-matchers'Hope this helps.
damonatbrightroll
commented
11 years ago @plribeiro3000 Tried that to no avail.
damonatbrightroll
commented
11 years ago This seems to be fixed by the merge to master resulting from https://github.com/thoughtbot/shoulda/issues/221#issuecomment-9261177.
gabebw
commented
11 years ago Fantastic! I'll close this then.
I also filed this at https://github.com/thoughtbot/shoulda/issues/224, but realized this may be a more appropriate location for it.
When running any of
rspec,rake spec,bundle exec rspec, orbundle exec rake specon my MacBook Pro, I see errors like this when running specs en masse:etc. The errors seem only to occur against shoulda-style specs. However, I can run individual RSpec files without incident, e.g.,:
Here is my Gemfile:
More info:
What's particularly troublesome is that I've got another project with basically the exact same Gemfile (the latter was used as a template for the former) and I've never seen this problem until now.
More information, after running with
rspec -b:I am also seeing this in our (Jenkins) CI environment.