Passing a model instance to a helper method in rspec testing - ruby-on-rails

I have a helper method in my app located in spec/support/utilities.rb
I am trying to pass an instance of a model object to it but I haven't succeeded so the tests fail
here is the helper method
def attribute_not_present(model_instance,model_attrib)
describe "when #{model_attrib} is not present" do
before { model_instance.send("#{model_attrib}=", " ") }
it { should_not be_valid }
end
end
in spec/model/tool_spec.rb i have this
require 'spec_helper'
describe Tool do
before do
#tool = FactoryGirl.create(:tool)
end
#attribute_array = ["kind", "serial_number", "department", "size",
"description", "hours", "length"]
subject { #tool }
#checks for absence of any of the required attributes
#attribute_array.each { |tool_attribute|
attribute_not_present(#tool,tool_attribute)
}
end
the #tool seems not to be recognized in the helper
the sample failure is this
1) Tool when size is not present
Failure/Error: before { model_instance.send("#{model_attrib}=", " ") }
NoMethodError:
undefined method `size=' for nil:NilClass
# ./spec/support/utilities.rb:3:in `block (2 levels) in attribute_not_present'
I am rails newbie

At the point where attribute_not_present is called, #tool does not yet exist. Moreover, in one case self is the example group, where when the spec is actually run (and inside your before blocks) self is an instance of the example group.
You don't need to pass model_instance through at all though - you could instead just use subject i.e.
before { subject.send("#{model_attrib}=", " ") }
however.
You may also want to look at shared examples.

Ok - I think I understand what you're trying to do here. You're trying to do unit tests, specifically validations on your Tool class, is that right?
If so, I personally like to use the shoulda_matchers gem which I find to be very idiomatic with exactly this.
As an example, you could do:
describe Tool do
it { should validate_presence_of(:kind) }
it { should validate_presnece_of(:serial_number) }
end
You can even do more with the validations, say you knew the :serial_number can only be an integer, you could do:
it { should validate_numericality_of(:serial_number).only_integer }
This is probably a better way to do unit level validations than a helper method as it's more Ruby-like.

Related

How to stub zendesk_api current_user for a spec?

I have a model method which I am trying to write a spec for. The method is like this:
def my_method
puts current_user.user_attirbute
end
Where current_user is provided by an authentication gem, zendesk_api-1.14.4. To make this method testable, I changed it to this:
def my_method(user_attribute = nil)
if user_attribute = nil
user_attribute = current_user.user_attribute
end
puts user_attribute
end
This refactor works and is testable, but doesn't seem like a good practice. Ideally the gem would provide some sort of test helper to help stub/mock the current_user, but I haven't been able to find anything. Any suggestions?
You can go simple way and just test returning of proper value by current_user#user_attribute method. Example:
describe '#my_method' do
subject { instance.my_method } # instance is an instance of your class where #my_method is defined
let(:user) { instance_spy(ZendeskAPI::User, user_attribute: attr) }
let(:attr} { 'some-value' }
before do
allow(instance).to receive(:current_user).and_return(user)
end
it { is_expected.to eq(attr) }
end
But I would go with VCR cassette(vcr gem is here) because it is related 3rd party API response - to minimize a risk of false positive result. Next example demonstrates testing with recorded response(only in case if #current_user method performs a request to zendesk):
describe '#my_method', vcr: { cassette_name: 'zendesk_current_user' } do
subject { instance.my_method }
it { is_expected.to eq(user_attribute_value) } # You can find the value of user_attribute_value in recorded cassette
end
P.S. I assumed that you put puts in your method for debugging. If it is intentional and it is part of the logic - replace eq with output in my example.

Cannot make rails spec for a request working : `undefined method 'call' for #<App:`

I'm trying make the specs work on a project. There was a setup for specs but was not maintain.
I have a simple post for a request spec
require 'rails_helper'
RSpec.describe 'Cars API', type: :request do
let(:organization) { Fabricate(:organization, owner: user) }
let(:app) { Fabricate(:app, organization: organization, owner: user) }
let(:user) { Fabricate(:user) }
before do
#login_api(user)
end
describe 'create' do
describe 'car type' do
it 'should create a car of type CarType1' do
expect(Car.count).to eql(0)
id = '123'
post("/api/1/organization/#{id}/cars")
expect(Car.count).to eql(1)
car = Car.first
expect(car.type).to eql(Car::CarType1)
end
end
end
end
And I get
#<NoMethodError: undefined method `call' for #<App:0x007fee64557080>>
I've tried to debug the issue but with no luck.
The issue happens at the line post("/api/1/organization/#{id}/cars").
Where might the problem be ?
I had such problem ;) (and spent several hours for debugging sources)
Try to rename app to ap or similar variable.
# "bad" name
let(:app) { ... }
# "better" name
let(:ap) { ... }
# or
let(:my_app) { ... }
As I understood the problem in variable name when RSpec initializes your lazy block let. Not sure but I think at that moment App has already initialized and RSpec send method call not to block from let but to another object.
Note: you can use before block and use instance variable #app
This issue is occuring because you are overriding the Rails app variable. Rename the variable to something else. It will work.
By default in rails, app variable is your Rails application which has call method that will be invoked whenever your application receives any request from Rack middleware.

RSpec & Rails: Stub #virtual_path for translation helper to test an application helper

I have a helper page_title_default in ApplicationHelper:
def page_title_default(options = {})
t '.title', options
end
Now I want to test it like this:
describe '#page_title' do
subject { page_title }
it { ... }
end
end
This results in the following error:
Cannot use t(".title") shortcut because path is not available
According to this post it should be possible to stub the #virtual_path variable like this:
helper.instance_variable_set(:#virtual_path, "admin.path.form")
But this doesn't seem to help: While I am able to stub it and then to call something like helper.t '.something' directly in the test, it doesn't work for the translation helper which is used in the page_title_default method (which still has #virtual_path set to nil). So it seems it's not the same instance of translation helper. But how can I find the page_title_default method one's?
How about something like:
RSpec.describe PageHelper, :type => :helper do
describe "#page_title_default" do
before do
allow(helper).to receive(:t).with(".title", {}) { "Hello!" }
end
subject { helper.page_title_default }
it { is_expected.to eq "Hello!" }
end
end
We're stubbing the "translated" string returned here to decouple the spec of helper from "real" translations, which may appear to be fragile for the test of PageHelper itself - the tests would fail every time you change the translations of ".title".
On the other hand - if you change the key used, eg. from ".title" to ".default_title" it should fail, because it is change of behaviour.
I think the proper text displayed should be tested on different level of test (integration tests, to be specific). Please, check the following answer.
Hope that helps!

Stubbing a helper method from inside helper specs

I'm building a Rails application and formulating tests using RSpec.
I wrote tests for a method I'm creating called current_link_to. This method is supposed to check whether the current page corresponds to the path I pass it and add the current class to the generated link in case it does.
Here is the spec:
require "spec_helper"
describe ApplicationHelper do
describe "#current_link_to" do
let(:name) { "Products" }
let(:path) { products_path }
let(:rendered) { current_link_to(name, path) }
context "when the given path is the current path" do
before { visit(path) }
it "should return a link with the current class" do
# Uses the gem "rspec-html-matchers" (https://github.com/kucaahbe/rspec-html-matchers)
expect(rendered).to have_tag("a", with: { href: path, class: "current" }) do
with_text(name)
end
end
end
context "when the given path is not the current path" do
before { visit(about_path) }
it "should return a link without the current class" do
expect(rendered).to have_tag("a", with: { href: path }, without: { class: "current" } ) do
with_text(name)
end
end
end
end
end
I then tried implementing my method following the spec:
module ApplicationHelper
def current_link_to(name, path, options={})
options.merge!({ class: "#{options[:class]} current".strip }) if current_page?(path)
link_to(name, path, options)
end
end
However, the tests fail with the following error:
Failure/Error: let(:rendered) { current_link_to(name, path) }
RuntimeError: You cannot use helpers that need to determine the current page unless your view context provides a Request object in a #request method
Since I don't really need the current_page? helper method to perform checks on the request, I decided that it would make sense to stub it.
I tried the following methods, but none of them worked:
helper.double(:current_page? => true)
Seems to stub the helper.current_page? method, but it's not the same method that's being called by my function.
allow(ActionView::Helpers::UrlHelper).to receive(:current_page?).and_return(true)
The stub seems not to be effective at all
While writing this question I stumbled onto the solution. I managed to stub the current_page? method using this in a before block:
allow(self).to receive(:current_page?).and_return(true)
It worked, however this solution raised more questions than it really answered. I am now baffled over how this works, as it seems weird that self in a before block would respond to current_page? and that said method would in fact be exactly the same one my helper is calling.
Even after reading documentation and trying to figure out how this works by littering my code with puts calls, the following doubts still haunt me:
Why are helper methods available directly in the specs, when the RSpec docs mention that they should instead be available as methods on the helper object available in all helper specs?
How does stubbing the current_page? method on self in a RSpec before block somehow reflect onto the actual method that gets called by my helper? Does self in my helper for some reason reference the same self you can find in the before block? Is RSpec or Rails including and mixing stuff under the covers?
If the same self encompasses my spec and my helpers, what exactly does self refer to in this case and why is it the same everywhere?
It would be great if someone could help me figure this out because this is blowing my mind up, and I'm scared of using code that I don't really understand.
With respect, you're testing a little too much functionality here. The trick is to test only the bits you need to test.
In this instance, you only need to test that the current class is added when it needs to be, and isn't when it doesn't need to be.
This code should do the trick for you:
require 'rails_helper'
# Specs in this file have access to a helper object that includes
# the ApplicationHelper.
RSpec.describe ApplicationHelper, type: :helper do
describe 'current_link_to' do
let(:subject) { helper.current_link_to('some_name', 'some_path', options = {}) }
context 'where the path is current' do
before do
allow(helper).to receive(:current_page?).and_return true
end
it 'should include the current class' do
expect(subject).to match /current/
end
end
context 'where the path is not current' do
before do
allow(helper).to receive(:current_page?).and_return false
end
it 'should not include the current class' do
expect(subject).to_not match /current/
end
end
end
end
I've been a little glib and only tested for the presence of 'current' in the returned string. You could test for something like 'class="current"' if you want to be more precise.
The other key is the comment at the top of the page, which Rails inserts into blank helper specs for you:
# Specs in this file have access to a helper object that includes
# the ApplicationHelper.
That means that you can use 'helper' where in your comment above you were using 'self', which makes things a little clearer (imho)
Hope it helps!

How can I DRY up my Rspec/Capybara suite?

In my suite I have this in many it blocks:
let(:user) { create(:user) }
let(:plan) { Plan.first }
let(:subscription) { build(:subscription, user: user ) }
it "something" do
subscription.create_stripe_customer
subscription.update_card valid_card_data
subscription.change_plan_to plan
login_as user
end
How could I DRY this up so I don't have to duplicate all these lines across many files?
You can also create a method like
def prepare_subscription
subscription.create_stripe_customer
subscription.update_card valid_card_data
subscription.change_plan_to plan
end
And in your it block like so:
it "something" do
prepare_subscription
login_as user
end
You ain't checking value for that spec so it always green.
If you need prepare some data before test then you could put that code into helper and call it when needed in (for example) before block.
If you need check spec passing again and again then you could use shared examples.

Resources