I have generated some scaffolding for my rails app.
I am running the generated tests and they are failing.
for example
test "should create area" do
assert_difference('Area.count') do
post :create, :area => { :name => 'area1' }
end
assert_redirected_to area_path(assigns(:area))
end
This test is failing saying that :
1) Failure:
test_should_create_area(AreasControllerTest)
[/test/functional/areas_controller_test.rb:16]:
"Area.count" didn't change by 1. <3>
expected but was <2>.
There is only one field in the model : name. I am populating this so it cant be because I am failing to populate the only field.
I can run the site and create an area with the name 'area1'. So reality is succeeding, but the test is failing.
I cant ask why its failing, because Im sure theres not enough information here for anyone here to know why. Im just stuck at knowing what avenues to go down to work out why the test is failing. Even putting puts into the code dont print out...
What steps can I take to track this down?
Per the request above, and matching what I was expecting that you'd find when you dug into your logs, you have an authorization that isn't being met in your test.
#request and #response are also useful objects to look at (i.e. puts #response inside your test). I don't know what authentication you are using, but check RAILS_ROOT/lib for authenticated_test_helper, or the /lib, or /test of your authentication gem. You'll find methods for performing a login.
Related
I am following along with the Ruby on Rails Tutorial by Michael Hartl and am up to the point of running tests. The test is a simple "supposed to fail" test shown here:
test "should get about" do
get static_pages_about_url
assert_response :success
end
with the error being simply that the about page, controller method, and route do not yet exist. However when I run the test I get a massive block of code which fills up my terminal. This is just a small sampling as an example of what i'm seeing.
E
Error:
StaticPagesControllerTest#test_should_get_about:
NameError: undefined local variable or method `static_pages_about_url' for #<StaticPagesControllerTest:0x00007fe6682cc760 #_routes=nil, #NAME="test_should_get_about", #failures=[#<Minitest::UnexpectedError: Unexpected exception>], #assertions=0, #integration_session=#<#<Class:0x00007fe6685342c8>:0x00007fe66859fc58 #_routes=nil, #app=#<SampleApp::Application:0x000055d7735cea68 #_all_autoload_paths=["/home/clay/Programs/sample_app/app/channels", "/home/clay/Programs/sample_app/app/controllers", "/home/clay/Programs/sample_app/app/controllers/concerns", "/home/clay/Programs/sample_app/app/helpers", "/home/clay/Programs/sample_app/app/jobs", "/home/clay/Programs/sample_app/app/mailers", "/home/clay/Programs/sample_app/app/models", "/home/clay/Programs/sample_app/app/models/concerns"], #_all_load_paths=["/home/clay/Programs/sample_app/lib", "/home/clay/Programs/sample_app/vendor", "/home/clay/Programs/sample_app/app/channels", "/home/clay/Programs/sample_app/app/controllers", "/home/clay/Programs/sample_app/app/controllers/concerns", "/home/clay/Programs/sample_app/app/helpers", "/home/clay/Programs/sample_app/app/jobs", "/home/clay/Programs/sample_app/app/mailers", "/home/clay/Programs/sample_app/app/models", "/home/clay/Programs/sample_app/app/models/concerns"], #app=#<ActionDispatch::HostAuthorization:0x000055d774009820 #app=#<Rack::Sendfile:0x000055d774009988 #app=#<ActionDispatch::Static:0x000055d773fe4f98 #app=#<ActionDispatch::Executor:0x000055d773fe5088 #app=#<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x000055d77382f4d8 #name="ActiveSupport::Cache::Strategy::LocalCache", #local_cache_key=:active_support_cache_null_store_local_cache_4420, #app=#<Rack::Runtime:0x000055d773fe51f0 #app=#<Rack::MethodOverride:0x000055d773fe5290 #app=#<ActionDispatch::RequestId:0x000055d773fe5330 #app=#<ActionDispatch::RemoteIp:0x000055d773fe5420 #app=#<Rails::Rack::Logger:0x000055d773fe54e8 #app=#<ActionDispatch::ShowExceptions:0x000055d773fe5588 #app=#<ActionDispatch::DebugExceptions:0x000055d773fe56c8 #app=#<ActionDispatch::ActionableExceptions:0x000055d773fe5790 #app=#<ActionDispatch::Reloader:0x000055d773fe58f8 #app=#<ActionDispatch::Callbacks:0x000055d773fe5998 #app=#<ActionDispatch::Cookies:0x000055d773fe5a38 #app=#<ActionDispatch::Session::CookieStore:0x000055d773fe5c68 #app=#<ActionDispatch::ContentSecurityPolicy::Middleware:0x000055d773fe5d58 #app=#<ActionDispatch::PermissionsPolicy::Middleware:0x000055d773fe5e20 #app=#<Rack::Head:0x000055d773fe5ec0 #app=#<Rack::ConditionalGet:0x000055d773fe5f60 #app=#<Rack::ETag:0x000055d773fe6050 #app=#<Rack::TempfileReaper:0x000055d773fe60f0
All I really need is the NameError: undefined local variable or method 'static_pages_about_url' and the location of the failing test right? Is this standard for failing tests in Ruby on Rails or is there a way to change how error messages are displayed from showing all of this less useful information?
In test driven development (TDD), you write the tests first. When you run them, all of them will be failing because you have not written the implementation yet (this is your "Red"). After that, you write the implementation that makes the tests pass (this is your "Green"). Once all tests are passsing, it comes the stage where you refactor the implementation (if required, this is your "Refactor"). Red, Green, Refactor.
In your particular example, you have written the test that checks if you can "GET" the about page but because you have not yet implemented the solution, your tests are failing.
In order to make the test pass, you'll need to add this to your route.rb file.
get 'static_pages/about'
Are rails 5.1 system tests supposed to reset the test database with original fixture data between each test?
This is not happening for me even between completely different test classes. One of my system tests is:
test 'delete thing' do
# deletes a thing from the fixture data
end
then I have another test that just looks to see if the thing is there
test 'view thing' do
# tries to view the thing
end
The test passes if the "view thing" test is ran first. If the "delete thing" test runs first then when my system test tries to view the thing then it fails.
I thought Rails system tests were resetting the data just like all the other tests. Is this not the case? Am I missing something?
Solved this one by changing the number of workers in our config/puma.rb file to 0 instead of 1.
Changing
workers ENV.fetch("WEB_CONCURRENCY") { 1 }
to
workers ENV.fetch("WEB_CONCURRENCY") { 0 }
fixed the issue for us.
I have just been dealing with this exact issue this morning, and I think I have figured it out.
This doc on fixtures helped me a bit: http://api.rubyonrails.org/v5.1.4/classes/ActiveRecord/FixtureSet.html.
For me though, I just had to make sure i was using the ModelName.method approach when my test involved modifying data (like adding and deleting records) as this interacts with the test database and does not change your fixtures. At first I was using the fixture_name.method for both reading and writing, and that led to unexpected results.
So for example, with a model of Blog and a fixture file blogs.yml with one record in it (hashed to key = :one):
test "view blog" do
get blog_path blogs(:one).id
assert_response :success
*OR*
get blog_path Blog.first.id
assert_response :success
end
But if modifying, stick with the second approach:
test "delete blogs" do
assert_equal 1, Blog.count
assert_equal Blog.first.id, blogs(:one).id
Blog.destroy_all
assert_equal 0, Blog.count
assert_raises(NoMethodError) { Blog.first.id }
assert_nothing_raised { blogs(:one).id }
end
test "before_or_after_delete_blogs" do
assert_equal 1, Blog.count
assert_equal Blog.first.id, blogs(:one).id
end
Both of those should pass.
Apologies if my explanation is off base. If that's the case, could you provide a little more context with your example?
I use the gem database_cleaner. Not sure if that's exactly the answer to your problem.
Also this could help?
rake db:test:prepare
Not too sure if your issue but hopefully that helps
My problem is that we're receiving mysterious 504 errors in SolanoCI, and I'm trying to find a clean way to handle them only in the test environment without adding test-specific code to our ApplicationController.
I've tried stubbing a default handler via the test setup like so:
allow(ApplicationController).to receive(:timeout).and_return {
#do a bunch of stuff to try to pull out request information
}
but I'm finding that it's lacking some important information that's accessible, like the original request url and any stacktrace information.
Any suggestions are welcome.
I think the easiest way for you in this situation would be to ask Solano to run a debugging session on their box for you (they give you ssh access to their server, so you may run tests yourself).
This is a real time saver in a black box situations like this. You may run tests multiple times and use all sorts of debugging tools there. You may have to install them first, since Solano tries not to install extra tools from your Gemfile (such as pry) to minimize test's running time.
Just write them via a contact form and they will give you an access. Don't forget to stop that session after you've done with it, since the time it runs is deducted from worker hours in your plan.
Hope it helps.
EDIT: It seems Anonymous controller feature is perfect for your case:
Use the controller method to define an anonymous controller that will
inherit from the described class. This is useful for specifying
behavior like global error handling.
So, you can do something like this:
RSpec.describe ApplicationController, :type => :controller do
controller(ApplicationController) do
rescue_from Timeout::Error, :with => :log_timeout
def log_timeout(error)
# log error as you wish
end
end
describe "handling timeout exceptions" do
it "writes some logs" do
get :index
expect(response).to have_https_status(504)
end
end
end
I'm new to Ruby On Rails. I love, it has Testing capabilities built in. But, I can't wrap around my head with testing. Here is my first basic Question about it.
What happens during testing really?
I understand development, we want some result, we use the data we have or get it from users to achieve the end result we want. But, the notion of testing seems sometimes confusing for me. I have been testing applications in browser for some time, are we replicating the same with code? Is it what testing is about? Replicating browser testing with automated code? Enlighten Me here.
Reading A Guide to Testing Rails Applications will be a good starting point.
Basically, you have three kinds of tests: unit, functional and integration.
Unit tests are testing your Models. In these tests you check whether a single method of your model works as expected, for example you set assign a login with spaces, and then you test whether the spaces were removed:
class UserTest < ActiveSupport::TestCase
def test_login_cleaning
u = User.new
u.login = " login_with_spaces "
assert_equal "login_with_spaces", u.login
end
# ... and other tests
end
Functional tests are testing your controllers (and views). In each test you simulate one request sent to one controller with given set of parameters, and then you ensure that the controller returned the proper response.
Note however, that in this test you cannot test the rendering of the page, so it's not strictly simulating a browser. To test whether your page looks nicely, you need to do it manually (I am almost sure some techniques exist, but I do not know of them).
An example of functional test:
class UserControllerTest < ActionController::TestCase
def test_show_renders_admin
get :show, :id => 1
assert_response :success
assert_select "div.user" do
assert_select "span.name", "Joe Admin"
end
end
def test_show_handles_unknown_id
get :show, :id => 9999
assert_response 404
assert_select "p.warning", "No such user"
end
end
Integration tests are testing a sequence of requests - something like a scenario, where an user logins, gets the 'create user' page, creates an user, and so on. These tests check whether the single requests (tested in functional tests) are able to work together.
I see that Simone already pointed the importance of automation in tests, so the link to the Guide is the only value in my answer ;-)
You may find it very helpful to apply some rules of Test Driven Development, especially when your project matures a little.
I know that it's not easy to start the project by writing test, because often you do not yet know how everything will work, but later, when you find a bug, I strongly suggest to start fixing every bug from writing a failing test case. It really, really helps both in the bug-fixing phase, and later - ensuring that the bug does not reappear.
Well, I noticed that I did not directly answer your question ;-)
When you start test procedure, Rails:
deletes the test database (so make sure you do not have any valuable data here),
recreates it using the structure of the development database (so, make sure you have run all your migrations),
loads all the fixtures (from test/fixtures/*)
loads all the test classes from test/units/* and other directories,
calls every method whose name starts with 'test_' or was created by the macro test "should something.." (alphabetically, but you may consider the order as being random)
before every call it executes a special setup procedure, and after every call it executes teardown procedure,
before every call it may (depending on the configuration) recreate your database data, loading the fixtures again.
You will find more information in the Guide.
What happens during testing is that you really run a set of specialized programs or routines (test code) that calls routines in your application (code under test) and verifies that they produce the expected results. The testing framework usually has some mechanism to make sure that each test routine is independent of the other tests. In other words the result from one test does not affect the result of the others.
In Rails specifically you run the tests using the rake test command line tool. This will load and execute each test routine in a random order, and tell you if each test was successful or not.
This answer doesn't necessary apply to Rails itself. When you talk about testing in Rails, you usually mean automatic testing.
The word automatic is the essence of the meaning. This is in fact the biggest difference between unit testing and "browser" testing.
With unit testing you essentially write a code, a routine, that stresses a specific portion of your code to make sure it works as expected. The main advantages of unit testing compared to "browser" testing are:
It's automatic and can be run programmatically.
Your test suite increases during the development lifecycle.
You reduce the risk of regression bugs, because when you modify a piece of code and you run the test suite, you are actually running all the tests, not just a random check.
Here's a basic, very simple example. Take a model, let's say the User model. You have the following attributes: first_name, last_name. You want a method called name to return the first and last name, if they exist.
Here's the method
class User
def name
[first_name, last_name].reject(&:blank?).join(" ")
end
end
and here's the corresponding unit test.
require 'test_helper'
class UserTest < ActiveSupport::TestCase
def test_name
assert_equal "John Doe", User.new(:first_name => "John", :last_name => "Doe").name
assert_equal "John", User.new(:first_name => "John").name
assert_equal "Doe", User.new(:last_name => "Doe").name
assert_equal "", User.new().name
end
end
I'm using rr (the mocking framework) and rspec with ruby-on-rails. Also, I'm using the collection short hand for partial rendering. My question: How do I correctly fill out the the following view spec?
describe 'my_view' do
before(:each) do
assigns[:models] = Array.new(10, stub(Model))
end
it "should render the 'listing' partial for each model" do
# help me write something that actually verifies this
end
end
I've tried a few examples from the rspec book, rspec docs, and rr docs. Everything I try seems to leave me with runtime errors in the test - not failed assertions. Rather than show all the transformations I've tried, I figured all I'd need if someone showed me one that actually worked. I'd be good to go from there.
I would suggest asserting the presence of some HTML that the "listing" partial should generate. Otherwise, it sounds like you're trying to assert that Rails is technically calling render on the partial? That's the job of the Rails core tests to prove such functionality.