Minitest crashes every time a test fails when I run rails test (Rails 5 and Ruby 2.4.2). For example, I forced a simple test to fail by switching the assert to assert_not:
Failure: TransactionTest#test_transaction_should_be_valid [/home/.../test/models/transaction_test.rb:11]: Expected true to be nil or false
/home/.../.rvm/gems/ruby-2.4.2/gems/railties-5.1.4/lib/rails/test_unit/reporter.rb:70:in `method': undefined method `test_transaction_should_be_valid' for class `Minitest::Result' (NameError)
If the test passes, then the entire report is successful and I get the report summary. If only one test fails I get the error report above. I defined test_transaction_should_be_valid in my transaction_test.rb file and the proof of it is that it runs smoothly when the test passes.
I'm stuck on this now. Any ideas as to what might be causing this?
Apparently Rails is not yet quite compatible with Minitest 5.10/5.11: https://github.com/seattlerb/minitest/issues/730 They have posted a monkeypatch to tide us over.
Rails has apparently also fixed this in edge. https://github.com/rails/rails/pull/31624
This error disappeared for me when I pulled from the master branch. Put this in your Gemfile:
gem 'rails', git: 'https://github.com/rails/rails.git'
edit: promoting from comments (thanks coco9nyc):
or you can try downgrading minitest:
gem 'minitest', '5.10.3'
Related
Recently my tests are started failing with following exception.
NoMethodError:
undefined method `and' for #<Capybara::RSpecMatchers::Matchers::HaveText:0x00007f97687dbe30>
Did you mean? end
My tests looks like
it "starts german but allows to be changed to english" do
within(".e-header") do
# german locale
expect(page).to have_content("Mein Anliegen").and not_have_content("My issue")
end
end
Rspec 3.10 documentation for compound expectations still supporting it. I am not sure why suddenly my tests started failing.
it looks like capybara will not include compound module if rspec expectations is not be defined (in other words, not require yet)
so try require "rspec/expectations" explicitly.
the reason:
it was due to the version range of RSpec we supported combined with the fact that a few people complained when we did because some people didn't want RSpec::Expectations. Most people don't run into this issue because they're using Capybara with rspec-rails.
A very similar error happened when I ran my test suite with Spring enabled:
undefined method `and' for #<Capybara::RSpecMatchers::Matchers::HaveSelector
The answer in the comment by Asad Ali helped, just added:
bundle add rspec-expectations --group test
And the specs work with Spring.
I am attempting to stub a Java static method in my specs for my JRuby class which imports some Java libraries. I get the following error for the method call:
Failure/Error: JCoDestinationManager.getDestination('properties')
ArgumentError:
Wrong number of arguments. Expected 0, got 1.
That's the JCo Java static method. I created a small spec file to try and isolate the issue:
require 'rails_helper'
describe SapClient do
let(:destination) { double(Java::ComSapConnJcoRt::RfcDestination) }
before do
allow(JCoDestinationManager).to receive(:getDestination).and_return destination
end
it 'can be created' do
c = SapClient.new
expect(c).to_not be_nil
end
end
If I add the with clause like so, I still get the same result.
allow(JCoDestinationManager).to receive(:getDestination).with('properties').and_return destination
The strange part to me is that I only encounter this project in rails. If I copy the code over to a Sinatra project and run these specs there, all is well. I created a new Rails project and a new Sinatra project and installed the same versions of RSpec, verified RSpec mocks were the same version, etc. and still saw the discrepancy in behavior.
When I throw in a pry and observe what happens when I just call
JCoDestinationManager.getDestination
With no arguments, I get the mock destination that I define. If I comment out the allow statement, I see a real RfcDestination get created.
While searching, only thing I saw that seemed close to what I'm observing here is from https://github.com/rspec/rspec-mocks/issues/919 but apparently the solution to this problem was a jruby issue that has since been fixed.
Rails Gemfile
Rails Gemfile.lock
Sinatra Gemfile
Sinatra Gemfile.lock
I've been having major problems with the airbrake gem that is seriously impeding my work flow lately. As an example, I am working on some front end stuff with coffeescript. When I make an error like a typo or anything, I get this error message:
As you can see from the image, this does not help me at all whatsoever and it takes me absolutely forever to figure out what's wrong. A second example is running a rake test.
When I have airbrake and run rake test, if I were to say have something wrong with mhy configuration, I get this horrible long string of text that looks like this:
Basically what the picture is saying is that I didn't specify the name of my localhost test database but you wouldn't necessarily know that based on the errors that airbrake yields.
In my airbrake.rbg I have the following configuration settings:
Airbrake.configure do |config|
config.project_key = ENV['AIRBRAKE_API_KEY']
config.host = "#{ENV['AIRBRAKE_HOST']}:#{ENV['AIRBRAKE_PORT'].to_i}"
config.project_id = ENV['AIRBRAKE_PROJECT_ID']
config.ignore_environments = %w(development test)
end
class Airbrake::Sender
def json_api_enabled?
true
end
end
As you can see, I should have airbrake configured correctly to ignore both my test and development database but this is not working. Has anyone had this problem before. I would really love to fix this once and for all so its not a huge problem anymore. Any help would be appreciated, thanks.
This looks like it is a bug in an older version of Airbrake that has been resolved in newer versions.
Try updating Airbrake in your Gemfile to the latest version.
gem 'airbrake', '~> 5.5'
I'm using SimpleCov with my rails app. Everything is working, but there seems to be a bug or i'm doing something wrong.
My test coverage when I run rake test comes back at 90.77%.
Then rake test TEST=test/path/to/file_test which returns 66%.
Finally, rake test and the coverage returned is 66%.
Is there some caching issue i'm missing? Also, I've notice all the sudden on the low 66% it seems to be counting all the blank lines as failed(see img).
It's caused by this bug at the merge process: https://github.com/colszowka/simplecov/issues/444. The suggested workaround worked for me:
At lib/simplecov/merge_helpers.rb replace if element.nil? && new_array[i].nil? with if element.nil? || new_array[i].nil?
All credit goes to ksmurphy.
I'm struggling with this for quite a while now: I'm trying to upgrade an app from Rails 3.2 to Rails 4. While on Rails 3.2 all specs are passing, they fail under certain conditions in Rails 4.
Some specs are passing in isolation while failing when run together with other specs.
Example Video
https://www.wingolf.org/ak-internet-files/Spec_Behaviour.mp4 (4 mins)
This example video shows:
Running 3 specs using :focus–––green.
Running them together with another spec–––two specs passing before now fail.
Running the 3 specs, but inserting two empty lines–––one spec fails.
Undo does not help when using guard.
focus/unfocus does not help.
Restarting guard does not help.
Running all specs and then running the 3 specs again does help and make them green again. But adding the other task makes two specs fail, again.
As one can see, some specs are red when run together with other specs. Even entering blank lines can make a difference.
More Observations
For some specs, passing or failing occurs randomly when run several times.
The behavior is not specific to one development machine but can be reproduced on travis.
To delete the database completely between the specs using database_cleaner does not help.
To Rails.cache.clear between the specs does not help.
Wrapping each spec in an ActiveRecord::Base.transaction does not help.
This does occur in Rails 4.0.0 as well as in Rails 4.1.1.
Using this minimal spec_helper.rb without spring or anything does not help.
Using guard vs. using bundle exec rspec some_spec.rb:123 directly doesn't make a difference.
This behavior goes for model specs, thus doesn't have to do anything with parallel database connections for features specs.
I've already tried to keep as many gems at the same version as in the (green) Rails-3.2 branch, including guard, rspec, factory_girl, etc.–––does not help.
Update: Observations Based on Comments & Answers
Thanks to engineerDave, I've inserted require 'pry'; binding.pry; into one of the concerning specs. Using the cd and show-source of pry, it was ingeniously easy and fun to narrow down the problem: Apparently, this has_many :through relation does not return objects when run together with other specs, even when called with (true).
has_many(:groups,
-> { where('dag_links.descendant_type' => 'User').uniq },
through: :memberships,
source: :ancestor, source_type: 'Group'
)
If I call groups directly, I get an empty result. But if I go through the memberships, the correct groups are returned:
#user.groups # => []
#user.groups(true) # => []
#user.memberships.collect { |m| m.group } # returns the correct groups
Has Rails changed the has many through behavior in Rails 4 in a way that could be responsible? (Remember: The spec works in isolation.)
Any help, insights and experiences are appreciated. Thanks very much in advance!
Code
Current master branch on Rails 3.2––all green.
Rails-4 branch––strange behavior.
The file/commit seen in the video––strange behavior.
All specs passing on travis for Rails 3.2.
Diff of the Gemfile.lock (or use git diff master..sf/rails4-minimal-update Gemfile.lock |grep rspec)
How to Reproduce
This is how one can check if the issue still exists:
Preparation
git clone git#github.com:fiedl/wingolfsplattform.git
cd wingolfsplattform
git checkout sf/rails4-minimal-update
bundle install
# please create `config/database.yml` to your needs.
bundle exec rake db:create db:migrate db:test:prepare
Run the specs
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb:213
The problem still exists, if the spec :213 is green in the second call but is red when run together with the other specs in the first call.
Based on that you're using:
the should syntax
that you indicate you've upgraded recently (perhaps a bundle update?)
that your failure messages indicate a NilObject error.
Is something like this perhaps what is causing it?
https://stackoverflow.com/a/16427072/793330
Are you are calling an object in your test which hasn't been instantiated yet?
I think this might be an rspec 3 upgrade issue where should is deprecated.
Have you ruled out an rspec gem upgrade to the new rspec 3 syntax (2.99 or 3.0.0+) as the culprit?
"Remove support for deprecated expect(...).should. (Myron Marston)"
IMO this behavior would not be caused by a Rails 4 update as its centered around your test suite.
Update (with pry debug):
Also you could use the pry gem to get a window into what is going on in your specs.
Essentially you can put a big "stop" sign (similar to a debug break) right before the spec executes to get a handle on the environment at that point.
it {
require 'pry'; binding.pry
should == something
}
Although beaware sometimes these pry calls wreck havoc on guard's threading and you have to kill it with CTRL+Z and then kill -9 PID that shows.
Update #2: Looking at updated answer.
You might be running up against FactoryGirl issues based on your has_many issue
You may need to trigger a before action in your Factory to pre-populate the associated record. Although this could get messy, i.e. here be monsters, you can trigger after and before callbacks in your factory that will bring these objects into being.
after(:create) do |instance|
do stuff here
end