I am new with Ruby/Rails and the testing frameworks within Ruby/Rails. I have a pre-validation method (external API) that validates the incoming request. For all test cases, I want to stub that call and test the remaining functionalities.
I am knowledgeable about testing and mocks/stubs/spies (mostly Mockito/Powermockito stuffs), but do not know my way around Rails testing. I tried looking into RSpec / MiniTest stuffs, but it is getting overwhelming.
I have a controller method like this:
def handler
# validate
request_validated = validate_request
unless request_validated
head :unauthorized
return
end
#... remaining codes
end
def validate_request
# validation with external API
end
I have controller tests set up using ActionController::TestCase. Prior to adding the validation stuffs, all my test cases have tested out. But I cannot stub around the validation check.
I would want to have something like
controller.stub(validate_request).then_and_return(true) # need something of this sort
post :handler, as: :json, params: completed_service_parameters
assert_response :no_content
I'm open to using any library, though would prefer to use any Rails in-built, if there's anything. Thanks.
I ended up using 'minitest/stub_any_instance'
require 'minitest/stub_any_instance'
...
test 'test stub' do
...
Controller.stub_any_instance(:function, return-value) do
# perform the call within the stubbed block
post :function, as: :json, params: { :param1 => 'random' }
end
...
end
Let's say we have Users (who can create Doorkeeper::Applications). On the other hand our app has Admins who ideally need to check each Application that is created (and maybe do a background check on the creating User and what not) as well as its scopes. They would #approve! or #reject! the Application and only once it is approved, can the Application make calls to the API.
NOTE: #approve!, #reject!, and approved do not come with Doorkeeper, from what I know. They are hypothetical so my question is clearer.
Is this a behavior that can be achieved with Doorkeeper (or an extension)? I don't think something like this is described in the config file. If not, do you have any general steps on how this could be done?
I'm thinking that something like this could work
class Api::V1::TransactionalBaseController < Api::V1::AuthableController
before_action :doorkeeper_authorize!
before_action :check_application_status!
private
def check_application_status!
application = doorkeeper_token.application
unless application.approved?
raise Doorkeeper::Errors::ApplicationForbidden.new
end
end
end
If this is something that may help other users of the gem, I'm open to possibly opening a PR or developing an extension to achieve this.
rails g migration AddApprovedAtRejectedAtToOauthApplications approved_at:datetime rejected_at:datetime
Edit the file to reflect the correct table.
Keeping in mind that Ruby lets you modify a class from anywhere... In an initializer (or similar); from https://github.com/doorkeeper-gem/doorkeeper/issues/153:
doorkeeper_extend_dir = File.join(Rails.root, "app", "models", "doorkeeper")
Dir.glob("#{doorkeeper_extend_dir}/*.rb").each { |f| require(f) }
# app/models/doorkeeper/application.rb
module Doorkeeper
class Application < ActiveRecord::Base
def approved?
approved_at?
end
def rejected?
rejected_at?
end
def approve!
update_column(:approved_at, DateTime.now)
end
def reject!
update_column(:rejected_at, DateTime.now)
end
end
end
I can't get my EmailCallback::MailgunEmail < SpecialDelivery::Callback class to be included in execution. My problem is I'm not clear on where and how to create and call the new class mentioned in the readme. Currently when I fire of a POST request to the mount SpecialDelivery::Engine => "/email_events" endpoint with all correct params, it is processed by SpecialDelivery::EventsController#create. An object is instantiated but not saved.
For reference; the gem readme section: https://github.com/vigetlabs/special-delivery#your-custom-callback-class-file
I ran the undocumented rake task (special_delivery:install:migrations) and migrated to new migration file.
I currently have:
# /lib/email_callback/mailgun_email.rb
module EmailCallback
class MailgunEmail < SpecialDelivery::Callback
def opened
require 'pry'; binding.pry
end
def create
require 'pry'; binding.pry
end
end
end
Note: I'm trying to hit the pry debugger to confirm the request is hitting the appropriate method and to see what I have to work with.
Thanks in advance for any help.
The new class should be referenced in your invocation of the #special_delivery method that wraps your email sending.
def send_your_email(user)
special_delivery(
callback_class: EmailCallback::MailgunEmail, # Here!
callback_record: user
) do
mail(to: user.email, subject: 'Hello from Kit!')
end
end
Let me know if that works for you. If not we can dive in a bit deeper and get this sorted out for you.
I am testing a controller and would like to force a db update to fail in order to verify that my error handling is working properly. I am fairly new to rails so I apologize if I am not following all of the best practices. Below is the relevant code:
Code is not complete as to focus on the important parts relevant to this question.
Controller:
class SomeController < ApplicationController
...
# relevant actions
def enable
able true
end
def disable
able false
end
...
private
def able (b)
...
# #dbobject will be set in a 'before_filter' function
if #dbobject.update_attribute(enabled: b)
# do some stuff
else # <------ need to force execution of this block
# error handling, logging, boring stuff
redirect_to #dbobject
...
end
...
end
Test:
class SomeController::AbleTest < ActionController::TestCase
tests SomeController
setup
# create #dbobject
end
test 'redirect occurs on update fail' do
get :enable, id: #dbobject
assert_redirected_to #dbobject
end
...
end
I also have tests in SomeController::AbleTest that require update_attribute to work properly so I would prefer to stay away from overriding the method completely. Is there any way to force the db to raise an exception if this record is accessed or something similar? I am not able to call the able method directly from the test class because it relies heavily on instance variables set by various before_filter methods and it feels too much like fighting the framework to not make the get :enable and have these methods run automatically.
You can use stubs. Look into mocha:
DBObject.any_instance.stubs(:update_attribute).returns(false)
This would mean whenever you can update_attribute on any instance of DBObject, it would return false, sending you into the else. So teh whole code would be:
test 'redirect occurs on update fail' do
DBObject.any_instance.stubs(:update_attribute).returns(false)
get :enable, id: #dbobject
assert_redirected_to #dbobject
end
Try using the mocha gem. You can temporarily stub update_attributes so it returns false.
dbobject.stubs(:update_attributes).returns(false)
Note that dbobject isn't the same as the #dbobject you're passing to get in your test. You'll have to stub the code that fetches the record in your controller. This is more troublesome than Yule's way of any_instance, so try that first.
I am working on some Cucumber stories for a 'sign up' application which has a number of steps.
Rather then writing a Huuuuuuuge story to cover all the steps at once, which would be bad, I'd rather work through each action in the controller like a regular user. My problem here is that I am storing the account ID which is created in the first step as a session variable, so when step 2, step 3 etc are visited the existing registration data is loaded.
I'm aware of being able to access controller.session[..] within RSpec specifications however when I try to do this in Cucumber stories it fails with the following error (and, I've also read somewhere this is an anti-pattern etc...):
Using controller.session[:whatever] or session[:whatever]
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.session (NoMethodError)
Using session(:whatever)
wrong number of arguments (1 for 0) (ArgumentError)
So, it seems accession the session store isn't really possible. What I'm wondering is if it might be possible to (and I guess which would be best..):
Mock out the session store etc
Have a method within the controller and stub that out (e.g. get_registration which assigns an instance variable...)
I've looked through the RSpec book (well, skimmed) and had a look through WebRat etc, but I haven't really found an answer to my problem...
To clarify a bit more, the signup process is more like a state machine - e.g. the user progresses through four steps before the registration is complete - hence 'logging in' isn't really an option (it breaks the model of how the site works)...
In my spec for the controller I was able to stub out the call to the method which loads the model based on the session var - but I'm not sure if the 'antipattern' line also applies to stubs as well as mocks?
Thanks!
I'll repeat danpickett in saying mocks should be avoided whenever possible in Cucumber. However if your app does not have a login page, or perhaps performance is a problem, then it may be necessary to simulate login directly.
This is an ugly hack, but it should get the job done.
Given /^I am logged in as "(.*)"$/ do |email|
#current_user = Factory(:user, :email => email)
cookies[:stub_user_id] = #current_user.id
end
# in application controller
class ApplicationController < ActionController::Base
if Rails.env.test?
prepend_before_filter :stub_current_user
def stub_current_user
session[:user_id] = cookies[:stub_user_id] if cookies[:stub_user_id]
end
end
end
mocks are bad in cucumber scenarios - they're almost kind of an antipattern.
My suggestion is to write a step that actually logs a user in. I do it this way
Given I am logged in as "auser#example.com"
Given /^I am logged in as "(.*)"$/ do |email|
#user = Factory(:user, :email => email)
#user.activate!
visit("/session/new")
fill_in("email", :with => #user.email)
fill_in("password", :with => #user.password)
click_button("Sign In")
end
I realize that the instance variable #user is kind of bad form—but I think in the case of logging in/out, having #user is definitely helpful.
Sometimes I call it #current_user.
Re. Ryan's solution - you can open up ActionController in you env.rb file and place it there to avoid putting in your production code base (thanks to john # pivotal labs)
# in features/support/env.rb
class ApplicationController < ActionController::Base
prepend_before_filter :stub_current_user
def stub_current_user
session[:user_id] = cookies[:stub_user_id] if cookies[:stub_user_id]
end
end
I don't know how much this relates to the original question anymore, but I decided to post anyway in the spirit of discussion...
We have a cucumber test suite that takes > 10 minutes to run so we wanted to do some optimization. In our app the login process triggers a LOT of extra functionality that is irrelevant to majority of the scenarios, so we wanted to skip that by setting the session user id directly.
Ryanb's approach above worked nicely, except that we were unable to log out using that approach. This made our multi-user stories fail.
We ended up creating a "quick login" route that is only enabled in test environment:
# in routes.rb
map.connect '/quick_login/:login', :controller => 'logins', :action => 'quick_login'
Here is the corresponding action that creates the session variable:
# in logins_controller.rb
class LoginsController < ApplicationController
# This is a utility method for selenium/webrat tests to speed up & simplify the process of logging in.
# Please never make this method usable in production/staging environments.
def quick_login
raise "quick login only works in cucumber environment! it's meant for acceptance tests only" unless Rails.env.test?
u = User.find_by_login(params[:login])
if u
session[:user_id] = u.id
render :text => "assumed identity of #{u.login}"
else
raise "failed to assume identity"
end
end
end
For us this ended up being simpler than working with the cookies array. As a bonus, this approach also works with Selenium/Watir.
Downside is that we're including test-related code in our application. Personally I don't think that adding code to make application more testable is a huge sin, even if it does add a bit of clutter. Perhaps the biggest problem is that future test authors need to figure out which type of login they should use. With unlimited hardware performance we obviously wouldn't be doing any of this.
Re: Ryan's solution:
Does not work with Capybara, unless small adaptation done:
rack_test_driver = Capybara.current_session.driver
cookie_jar = rack_test_driver.current_session.instance_variable_get(:#rack_mock_session).cookie_jar
#current_user = Factory(:user)
cookie_jar[:stub_user_id] = #current_user.id
(found here: https://gist.github.com/484787)
My understanding is that you get:
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.session (NoMethodError)
when session[] is accessed before request has been instantiated. In your case, I'd imagine if you put webrats' visit some_existing_path before accessing session[] in your step defenition, the error will go away.
Now, unfortunately, session doesn't seem to persist across steps (at least, I couldn't find the way), so this bit of information doesn't help to answer your question :)
So, I suppose, Ryan's session[:user_id] = cookies[:stub_user_id]... is the way to go. Although, imo, test related code in the application itself doesn't sound right.
I use a testing-only sign-in solution like Prikka's, but I do it all in Rack instead of creating a new Controller and routes.
# in config/environments/cucumber.rb:
config.middleware.use (Class.new do
def initialize(app); #app = app; end
def call(env)
request = ::Rack::Request.new(env)
if request.params.has_key?('signed_in_user_id')
request.session[:current_user_id] = request.params['signed_in_user_id']
end
#app.call env
end
end)
# in features/step_definitions/authentication_steps.rb:
Given /^I am signed in as ([^\"]+)$/ do |name|
user = User.find_by_username(name) || Factory(:user, :username => name)
sign_in_as user
end
# in features/step_definitions/authentication_steps.rb:
Given /^I am not signed in$/ do
sign_in_as nil
end
module AuthenticationHelpers
def sign_in_as(user)
return if #current_user == user
#current_user = user
get '/', { 'signed_in_user_id' => (user ? user.to_param : '') }
end
end
World(AuthenticationHelpers)
#Ajedi32 I ran into the same issue (undefined method 'current_session' for Capybara::RackTest::Driver) and putting this in my step definition fixed the problem for me:
rack_test_browser = Capybara.current_session.driver.browser
cookie_jar = rack_test_browser.current_session.instance_variable_get(:#rack_mock_session).cookie_jar
cookie_jar[:stub_user_id] = #current_user.id
In my controller action, I referred to cookies[:stub_user_id], instead of cookie_jar[:stub_user_id]
Why don't you use FactoryGirl or (Fixjour or Fabricator) with Devise (or Authlogic) and SentientUser? Then you can simply sniff which user is already logged in!
#user = Factory(:user) # FactoryGirl
sign_in #user # Devise
User.current.should == #user # SentientUser
Another slight variation:
# In features/step_definitions/authentication_steps.rb:
class SessionsController < ApplicationController
def create_with_security_bypass
if params.has_key? :user_id
session[:user_id] = params[:user_id]
redirect_to :root
else
create_without_security_bypass
end
end
alias_method_chain :create, :security_bypass
end
Given %r/^I am logged in as "([^"]*)"$/ do |username|
user = User.find_by_username(username) || Factory(:user, :username => username)
page.driver.post "/session?user_id=#{user.id}"
end
After a lot of soul searching and web surfing, I finally opt'ed for a very simple and obvious solution.
Using cookies adds two problems. First you have code in the application specific for testing and second there is the problem that creating cookies in Cucumber is hard when using anything other than rack test. There are various solutions to the cookie problem but all of them are a bit challenging, some introduce mocks, and all of them are what I call 'tricky'. One such solution is here.
My solution is the following. This is using HTTP basic authentication but it could be generalized for most anything.
authenticate_or_request_with_http_basic "My Authentication" do |user_name, password|
if Rails.env.test? && user_name == 'testuser'
test_authenticate(user_name, password)
else
normal_authentication
end
end
test_authenticate does what ever the normal authenticate does except it bypasses any time consuming parts. In my case, the real authentication is using LDAP which I wanted to avoid.
Yes… it is a bit gross but it is clear, simple, and obvious. And… no other solution I've seen is cleaner or clearer.
Note, one feature is that if the user_name is not 'testuser', then the normal path is taken so they can be tested.
Hope this helps others...