I have a controller like follows:
namespace :admin do
resources :posts
end
# app/controllers/admin_posts_controller.rb
module Admin
class PostsController < ApplicationController
end
end
The problem is I don't know where Admin::PostsControllerTest goes.
I was expecting something like following works:
# test/functional/admin/posts_controller_test.rb
module Admin
class PostsControllerTest < ActionController::TestCase
end
end
But if I do that I get the following error when I run rake test:functionals :
RuntimeError: #controller is nil: make sure you set it in your test's setup method.
You've got the right location. Try this:
class Admin::PostsControllerTest < ActionController::TestCase
#put your tests here
end
Related
Rails 3.2
In my controllers/admin/accounts_receivables_contoller.rb, I have:
class Admin::AccountsReceivables < Admin::ApplicationController
def index
...
end
and in one of the views, I have:
= link_to admin_accounts_receivables_path
In my config/routes.rb, I have:
namespace :admin do
resources :accounts_receivables do
collection do
get 'admin_report'
get 'customer_report'
post 'process_invoices'
end
end
end
rake routes, produces:
admin_accounts_receivables GET admin/accounts_receivables(.:format) admin/accounts_receivables#index
However, when I click on the link, I get (in the browser, but no entry in the log file):
uninitialized constant Admin::AccountsReceivablesController
I do not have a corresponding AccountsReceivable model, as I don't need it.
Any ideas?
The class should be named AccountsReceivablesController and you should nest the class explicitly instead of using the scope resolution operator so that it has the correct module nesting:
module Admin
class AccountsReceivablesController < ApplicationController
def index
# ...
end
end
end
When you use the scope resolution operator class Admin::AccountsReceivablesController - the module nesting is resolved to the point of definition which is Main (the global scope) and not Admin. For example:
module Admin
FOO = "this is what we expected"
end
FOO = "but this is what we will actually get"
class Admin::AccountsReceivablesController < Admin::ApplicationController
def index
render plain: FOO
end
end
See The Ruby Style Guide - namespaces.
class Admin::AccountsReceivables < Admin::ApplicationController
should be...
class Admin::AccountsReceivablesController < Admin::ApplicationController
I have the following setup:
class UsersController < ApplicationController
...
end
class Admin::BaseController < ApplicationController
...
end
class Admin::UsersController < Admin::BaseController
...
end
And likewise specs:
#spec/controllers/users_controller_spec.rb:
describe UsersController do
...
end
#spec/controllers/admin/users_controller_spec.rb
describe Admin::UsersController do
...
end
All the specs run fine when run independantly, however when I run all together I get the warning:
toplevel constant UsersController referenced by Admin::UsersController
And the specs from the admin controller don't pass.
Routes file:
...
resources :users
namespace "admin" do
resources :users
end
...
Rails 4, Rspec 2.14
Can I not use the same name for controllers in different namespaces?
This happens when a top level class get autoloaded before a namespaced one is used. If you have this code without any class preloaded :
UsersController
module AdminArea
UsersController
end
The first line will trigger constant missing hook : "ok, UsersController does not exist, so let's try to load it".
But then, reaching the second line, UsersController is indeed already defined, at top level. So, there's no const_missing hook triggered, and app will try to use the known constant.
To avoid that, explicitly require proper classes on top of your spec files :
#spec/controllers/users_controller_spec.rb:
require 'users_controller'
And
#spec/controllers/admin/users_controller_spec.rb
require 'admin/users_controller'
I have a rails model located at app/models/scheduling/availability.rb which looks like:
class Scheduling::Availability < ActiveRecord::Base
end
I have a Rails controller located at *app/controllers/admin/scheduling/availabilities_controller.rb* which looks like:
class Admin::Scheduling::AvailabilitiesController < ApplicationController
def index
#availabilities = Scheduling::Availability.all
end
end
My routes look like:
namespace :admin do
namespace :scheduling do
resources :availabilities
end
end
When trying to load the url:
/admin/scheduling/availabilities
I get the error:
uninitialized constant
Admin::Scheduling::AvailabilitiesController::Scheduling
I have a feeling this is because Rails is confusing the Scheduling module/namespaces.
What am I doing wrong?
Found my answer in another answer.
Need to preface my module with ::
class Admin::Scheduling::AvailabilitiesController < ApplicationController
def index
#availabilities = ::Scheduling::Availability.all
end
end
They don't seem to be accessible from ActionView::TestCase
That's right, helper methods are not exposed in the view tests - but they can be tested in your functional tests. And since they are defined in the controller, this is the right place to test them. Your helper method is probably defined as private, so you'll have to use Ruby metaprogramming to call the method.
app/controllers/posts_controller.rb:
class PostsController < ApplicationController
private
def format_something
"abc"
end
helper_method :format_something
end
test/functional/posts_controller_test.rb:
require 'test_helper'
class PostsControllerTest < ActionController::TestCase
test "the format_something helper returns 'abc'" do
assert_equal 'abc', #controller.send(:format_something)
end
end
This feels awkward, because you're getting around encapsulation by using send on a private method.
A better approach is to put the helper method in a module in the /controller/concerns directory, and create tests specifically just for this module.
e.g. in app controller/posts_controller.rb
class PostsController < ApplicationController
include Formattable
end
in app/controller/concerns/formattable.rb
module Concerns
module Formattable
extend ActiveSupport::Concern # adds the new hot concerns stuff, optional
def format_something
"abc"
end
end
end
And in the test/functional/concerns/formattable_test.rb
require 'test_helper'
# setup a fake controller to test against
class FormattableTestController
include Concerns::Formattable
end
class FormattableTest < ActiveSupport::TestCase
test "the format_something helper returns 'abc'" do
controller = FormattableTestController.new
assert_equal 'abc', controller.format_something
end
end
You could test #controller.view_context from your functional/controller tests. This method is available in Rails 3, 4, and 5, as far as I can tell.
app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
helper_method :current_user
# ...
end
test/controllers/application_controller_test.rb
require 'test_helper'
class ApplicationControllerTest < ActionController::TestCase
test 'current_user helper exists in view context' do
assert_respond_to #controller.view_context, :current_user
end
end
If you didn't want to test one of your controller subclasses, you could also create a test controller to verify that the method in the view_context is the same one from the controller and not from one of your view helpers.
class ApplicationControllerHelperTest < ActionController::TestCase
class TestController < ApplicationController
private
def current_user
User.new
end
end
tests TestController
test 'current_user helper exists in view context' do
assert_respond_to #controller.view_context, :current_user
end
test 'current_user returns value from controller' do
assert_instance_of User, #controller.view_context.current_user
end
end
Or, more likely, you'd want to be able to test the helper in the presence of a request.
class ApplicationControllerHelperTest < ActionController::TestCase
class TestController < ApplicationController
def index
render plain: 'Hello, World!'
end
end
tests TestController
def with_routing
# http://api.rubyonrails.org/classes/ActionDispatch/Assertions/RoutingAssertions.html#method-i-with_routing
# http://guides.rubyonrails.org/routing.html#connecting-urls-to-code
super do |set|
set.draw do
get 'application_controller_test/test', to: 'application_controller_test/test#index'
end
yield
end
end
test 'current_user helper exists in view context' do
assert_respond_to #controller.view_context, :current_user
end
test 'current_user returns value from controller' do
with_routing do
# set up your session, perhaps
user = User.create! username: 'testuser'
session[:user_id] = user.id
get :index
assert_equal user.id, #controller.view_context.current_user.id
end
end
end
I've struggled with this for a bit, because the accepted answer didn't actually test whether the method was exposed as a helper method.
That said, we can use the #helpers method to get a proxy for testing.
For example:
class FooController < ApplicationController
private
def bar
'bar'
end
helper_method :bar
end
Can be tested with:
require 'test_helper'
class FooControllerTest < ActionController::TestCase
test 'bar is a helper method' do
assert_equal 'bar', #controller.helpers.bar
end
end
Indeed they're not. The view tests are specifically for the views. They don't load the controllers.
You should mock this method and make it return whatever is appropriate depending of your context.
I have the following filter defined:
# application_controller.rb
class ApplicationController < ActionController::Base
before_filter :find_account
private
def find_account
#current_account = Account.find_by_subdomain!(request.subdomains.first)
end
end
and in my test:
# users_controller_test.rb
class UsersControllerTest < ActionController::TestCase
setup do
#request.host = "test.myapp.local"
end
# ...
end
Now test is defined as the subdomain for a dummy account that I load prior to all requests using factory_girl. However, this is throwing a nil object error, saying that #request is nil. Removing the setup block causes all of my tests to fail as find_account cannot find an account and therefore throws a RecordNotFound error.
What am I doing wrong?
Try this:
#request.env['HTTP_HOST'] = 'test.myapp.local'