Deprecation warning with "spring rspec" but not "rspec" - ruby-on-rails

When I run spec via bundler, I get no errors...
bundle exec rspec -fd spec/controllers/blah.rb
But when I run it via the binstub to use spring, I get lots of these errors:
./bin/rspec -fd spec/controllers/blah.rb
DEPRECATION WARNING: `serialized_attributes` is deprecated without replacement, and will be removed in Rails 5.0.
Why is this?
I have tried stopping and starting; no effect.
In config/environments/test.rb I have this:
# Print deprecation notices to the stderr.
config.active_support.deprecation = :stderr
For reference...
$ bundle list | grep -E '(rspec|spring)'
* rspec-core (3.0.4)
* rspec-expectations (3.0.4)
* rspec-mocks (3.0.4)
* rspec-rails (3.0.2)
* rspec-support (3.0.4)
* spring (1.7.2)
* spring-commands-rspec (1.0.4)
As requested, my ./bin/rspec file...
$ cat ./bin/rspec
#!/usr/bin/env ruby
begin
load File.expand_path('../spring', __FILE__)
rescue LoadError => e
raise unless e.message.include?('spring')
end
# frozen_string_literal: true
#
# This file was generated by Bundler.
#
# The application 'rspec' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require "pathname"
ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../../Gemfile",
Pathname.new(__FILE__).realpath)
require "rubygems"
require "bundler/setup"
load Gem.bin_path("rspec-core", "rspec")

Well one possible fix is to change this:
config.active_support.deprecation = :stderr
to
config.active_support.deprecation = :silence
However this does not answer why its suppressed for rspec, not not via spring?!

Related

Cannot define multiple 'included' blocks for a Concern (ActiveSupport::Concern::MultipleIncludedBlocks) minitest error

While running the minitests, I am getting this error ..
Cannot define multiple 'included' blocks for a Concern
(ActiveSupport::Concern::MultipleIncludedBlocks)
This is the command I am using
RAILS_ENV=test bundle exec ruby test/api/functional/f1/file_1.rb
Rails -v gives Rails 4.2.11.3
Ruby -v gives ruby 2.4.7p357 (2019-08-28 revision 67796) [x86_64-darwin19]
rvm -v gives rvm 1.29.9
require_relative '../../test_helper'
# require Rails.root.join('test', 'core', 'helpers', 'controller_test_helper.rb')
# require Rails.root.join('test', 'core', 'helpers', 'users_test_helper.rb')
Dir.glob("#{Rails.root}/test/core/helpers/*_helper.rb") { |file| require file }
class ABC::EFG < ActionController::TestCase
# tests Freshrelease::SettingsController
include FreshreleaseConfig
include UsersTestHelper
include ControllerTestHelper
def setup
super
before_all
end
Please help.
P.S it was successfully running before

Pry Remote / ByeBug next goes into Teardown

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

undefined method `expect' for #<Spinach::Features

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

rspec assert_equal no method error

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.

How can you load the Rails environment from CloudCrowd actions?

I'm writing an "action" for CloudCrowd which needs access to the Rails environment (for some ActiveRecord stuff) but the standard means of loading the environment is resulting in fishy errors.
I tried each of the following at the top of my action .rb file:
require(File.join(File.dirname(__FILE__), '../..', 'boot'))
and
require File.expand_path(File.dirname(__FILE__) + "/../../environment")
When I try to start the node I get this error:
»crowd node
Starting CloudCrowd Node on port 9063...
Missing the Rails 2.3.2 gem. Please `gem install -v=2.3.2 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.
And I of course do have the gem installed:
»gem list | grep -i rails
rails (2.3.4, 2.3.2, 2.2.2, 1.2.6)
Nice!
I've actually had some trouble with your RAILS_ROOT path and replaced '../../..' with '../..'. Also, since you've already declared the RAILS_ROOT constant, you could chop off a few things in the environment requirement. Here's my version:
RAILS_GEM_VERSION = nil
RAILS_ROOT = File.expand_path(File.join(File.dirname(__FILE__), '../..'))
RAILS_ENV = ENV['RAILS_ENV'] = ENV['RACK_ENV']
if CloudCrowd.node?
require 'rubygems'
require 'activerecord'
ActiveRecord::Base.logger = Logger.new(STDOUT)
require "#{RAILS_ROOT}/config/environment"
# and if you need to import
# anything from lib just go ahead and
require 'my_custom_lib/name_of_file'
end
Somebody from #documentcloud saw my plea and helped me work through it. Had to prefix the action script with this:
RAILS_GEM_VERSION = nil
RAILS_ROOT = File.expand_path(File.join(File.dirname(__FILE__), '../../..'))
RAILS_ENV = ENV['RAILS_ENV'] || 'development'
if CloudCrowd.node?
require 'rubygems'
require 'activerecord'
ActiveRecord::Base.logger = Logger.new(STDOUT)
require File.expand_path(File.join(File.dirname(__FILE__), '../..', 'environment'))
end

Resources