undefined method 'assert_equal' for #<RSpec::Core::ExampleGroup::Nested_1:0x8d6f75c>
gem list
bundler (1.3.5)
diff-lcs (1.2.3)
rspec (2.13.0)
rspec-core (2.13.1)
rspec-expectations (2.13.0)
rspec-mocks (2.13.1)
test-unit (2.5.4)
spec_helper.rb
require './lib/checkout.rb'
require './lib/product.rb'
require 'rspec'
RSpec.configure do |config|
config.treat_symbols_as_metadata_keys_with_true_values = true
config.run_all_when_everything_filtered = true
config.filter_run :focus
end
Try object.should eq('foo') or expect(object).to eq('foo') instead. As a side note, object.should == 'foo' will give you a Ruby warning when running with the -w flag.
Also, this is an assumption answer since you didn't give us any actual code.
Rather than change all your lines in a spec file you can add these at the top
require_relative '../spec_config'
and in that file put:
RSpec.configure do |config|
config.expect_with :minitest
end
because minitest has assert_equal method. Sorry I'm so late but I was just looking for answer myself to something and just happened to see this.
You can try object.should == "something". Here object means the object you want to test.
Related
So I've decided to split my last post since the bug is Related to ByeBug more than to Pry-Remote (I think). Last post URL: Pry-Remote not triggered Rails 4
Problem:
When typing Next in Pry-Remote, ByeBug acts unexpectedly and goes to "teardown".
Also created an ByeBug Issue:
https://github.com/deivid-rodriguez/pry-byebug/issues/78
What I am running:
gem 'pry-byebug', '=1.3.3'
gem 'pry-stack_explorer'
gem 'pry-rails'
gem 'pry-remote'
pry (0.10.2)
coderay (~> 1.1.0)
method_source (~> 0.8.1)
slop (~> 3.4)
pry-byebug (1.3.3)
byebug (~> 2.7)
pry (~> 0.10)
pry-rails (0.3.4)
pry (>= 0.9.10)
pry-remote (0.1.8)
pry (~> 0.9)
slop (~> 3.0)
pry-stack_explorer (0.4.9.2)
binding_of_caller (>= 0.7)
pry (>= 0.9.11)
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]
Rails 4.2.4
Note 1:
Updated all the pry related gems
https://gist.github.com/YOUConsulting/65cdcdc22d32780dde51
You seem to be using an ancient version of pry-byebug, the latest as of this writing is 3.2.0 but you're using 1.3.3. If you update your gems there's a good chance the problem will go away.
UPDATE
After further research it looks like pry-remote and pry-byebug do not work well together on Ruby 2.x.
However, there is a bit of code a coder posted, most of the comments are in Japanese, but they claim it makes pry-remote work. I'm including their code below (I've translated the Japanese as well):
module ObjectUtils
# remote parameter is the ip address, default port is 9876
def pry!(remote=nil, port=9876)
$LOAD_PATH.unshift "#{ENV['RUBY_PATH']}/debuger"
require 'pry'
return if __callee__ == :pry1 and !Pry.instance_variable_get(:#pry_is_start)
Pry.instance_variable_set(:#pry_is_start, true)
# if defined? Pry and defined? PryStackExplorer and Pry.config.hooks.hook_exists? :after_session, :delete_frame_manager
# Pry.config.hooks.delete_hook :when_started, :save_caller_bindings
# Pry.config.hooks.delete_hook :after_session, :delete_frame_manager
# end
if remote or ENV['USE_PRY_REMOTE']
if defined? PryNav
if defined? ActionDispatch # rails application.
if Pry.initial_session?
warn '[0m[33mloading pry remote ...[0m'
binding.of_caller(1).remote_pry(remote, port)
end
else
binding.of_caller(1).remote_pry(remote, port)
end
else
require_remote_debugger
binding.of_caller(1).remote_pry(remote, port)
`notify-send -t 5000 -- "exiting pry remote ..."` if find_executable 'notify-send'
end
else
# if these constants are defined then you're already in a debugger session
if defined? PryByebug or defined? PryDebugger or defined? PryNav
if defined? ActionDispatch # rails application.
if Pry.initial_session?
# When sending a new request, it will reset Pry.initial_sesssion? It is true.
# This ensures that, in the same request the debugger will be activated once.
# Only on the next request will it be reinitialized
warn '[1m[33mloading debugger ...[0m'
binding.of_caller(1).pry
end
else
binding.of_caller(1).pry
end
else
require_debugger
binding.of_caller(1).pry
end
end
end
def require_debugger
case RbConfig::CONFIG['ruby_version']
when '2.0.0'...'3.0.0'
require 'pry-byebug'
when '1.9.0'...'2.0.0'
require 'pry-debugger'
end
# to make sure the debugger is loaded
warn '[1m[33mloading debugger ...[0m'
require 'ap'; AwesomePrint.pry!
rescue LoadError
require 'pry-nav'
warn '[1m[33mloading debugger ...[0m'
end
def require_remote_debugger
require 'pry-remote'
require 'pry-nav'
warn '[0m[33mloading pry remote ...[0m'
`notify-send -t 10000 -- "loading pry remote ..."` if system 'which notify-send &>/dev/null'
require 'ap'; AwesomePrint.pry!
end
end
Kernel.send(:include, ObjectUtils)
Object.send(:include, Kernel)
You'll need to call these methods, and might need to tweak them for your usage.
References
https://github.com/Mon-Ouie/pry-remote/issues/58
https://github.com/Mon-Ouie/pry-remote/issues/35#issuecomment-20290739
https://github.com/deivid-rodriguez/pry-byebug/issues/33
https://rubygems.org/gems/pry-byebug
I've followed the README at the spinach repo as well as including spinach-rails instead of the base spinach gem.
Spinach documentation states:
# When using Capybara, you can switch the driver to use another one with
# javascript capabilities (Selenium, Poltergeist, capybara-webkit, ...)
#
# Spinach already integrates with Capybara if you add
# `require spinach/capybara` in `features/support/env.rb`.
Which I have done:
Head of my env.rb file:
require 'spinach-rails'
require 'spinach/capybara'
ENV['RAILS_ENV'] = 'feature'
require 'rspec'
require 'factory_girl_rails'
require 'webmock'
require 'coffee_script'
include WebMock::API
WebMock.disable_net_connect!(:allow_localhost => true)
require_relative '../../config/environment'
The step failing in the test reads:
step 'I see the Generals Page' do
expect(page).to have_content("Inventory")
end
When I inspect the Spinach::FeatureSteps class using RubyMine I can see two hits - one to the "base" class and the other to the capybara version:
require 'capybara'
require 'capybara/dsl'
require 'rbconfig'
require 'spinach/config'
require_relative 'feature_steps'
module Spinach
class FeatureSteps
# Spinach's capybara module makes Capybara DSL available in all features.
#
# #example
# require 'spinach/capybara'
# class CapybaraFeature < Spinach::FeatureSteps
# Given "I go to the home page" do
# visit '/'
# end
# end
#
module Capybara
include ::Capybara::DSL
Which really makes it seem like there should be a switch of sorts in the spinach configuration that lets me choose to use the capybara DSL in my tests.
But it doesn't appear to be working properly.
How can I get Capybara working with Spinach?
Gemfile.lock:
spinach (0.8.10)
colorize
gherkin-ruby (>= 0.3.2)
json
spinach-rails (0.2.1)
capybara (>= 2.0.0)
railties (>= 3)
spinach (>= 0.4)
test and feature group in Gemfile:
group :test, :feature do
gem "factory_girl_rails"
gem "capybara"
gem "webmock"
gem "capybara-webkit"
gem "spinach-rails"
end
I have an existing project using mongoid, database_cleaner and rspec. I try to add active_admin, using the active_admin patches available. ActiveAdmin assumes it is in an ActiveRecord project, most specifically via its dependence on the meta_search gem.
When I go to run my specs, they all fail with the following error:
Failure/Error: Unable to find matching line from backtrace
ActiveRecord::ConnectionNotEstablished:
ActiveRecord::ConnectionNotEstablished
# ./spec/support/database_cleaner.rb:12:in `block (2 levels) in <top (required)>'
The gem versions of the related libraries are as follows:
activeadmin (0.4.2)
database_cleaner (0.7.1)
mongoid (2.4.5)
meta_search (1.1.3)
activerecord (3.2.1)
The file that the tests are failing on, spec/support/database_cleaner.rb:
require 'database_cleaner'
RSpec.configure do |config|
config.before(:suite) do
DatabaseCleaner.strategy = :truncation
DatabaseCleaner.orm = "mongoid"
end
config.before(:each) do
DatabaseCleaner.clean
end
end
[moved from question]
It appears that database_cleaner attempts to autodetect the ORMs available to it in its initialization method
This can be pre-empted by changing the spec/support/database_cleaner.rb file like so:
RSpec.configure do |config|
config.before(:suite) do
DatabaseCleaner[:mongoid].strategy = :truncation
end
end
Calling the [] method in configuration overrides the autodetect such that ActiveRecord is no longer added.
Another workaround would have been to re-add a config/database.yml file with a sqlite3 configuration that the rest of the application ignored. Thankfully that isn't necessary.
#/features/support/env.rb
...
require 'database_cleaner'
require 'database_cleaner/cucumber'
require 'database_cleaner/mongo_mapper/truncation'
DatabaseCleaner.strategy = :truncation
Before do
DatabaseCleaner.start
end
After do
DatabaseCleaner.clean
end
Result
Exception encountered by DatabaseCleaner in Cucumber After block: ActiveRecord::ConnectionNotEstablished
If I comment Before and After block - tests work fine without DatabaseCleaner
ree-1.8.7-2011.03
rails (2.3.12)
mongo_mapper (0.7.5)
cucumber (0.8.7)
cucumber-rails (0.3.2)
database_cleaner (0.6.7)
looks like it's still using ActiveRecord, try disabling it
when I run rspec spec/models result is OK.
But when I use spork, every test where shoulda macros (like it { should validate_presence_of(:title) } is used FAILS with error like: undefined method 'validate_presence_of' for ...
I use:
rails (3.0.0)
shoulda (2.11.3)
spork (0.8.4)
rspec-rails (>= 2.0.0.beta.22)
spec/spec_helper.rb:
require 'rubygems'
require 'spork'
Spork.prefork do
# 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 'shoulda'
...
I had the same issue. Fixed it by sticking require 'shoulda/integrations/rspec2' after requiring rspec/rails in prefork block.
You might also want to upgrade your spork to the latest version (gem 'spork', >= 0.9.0.rc2), since I didn't try this fix on 0.8.4 (although I am pretty sure it'll work too)
Try moving the
require "shoulda"
line into the Spork.each_run block. Apparently, shoulda does some magic to include the matchers into the appropriate example groups.