When I run integrations tests with Capybara/webkit I get this error message:
undefined|36|TypeError: Result of expression 'node' [undefined] is not an object.
However it doesn't cause the test to fail and it doesn't always occur. When it does occur it seems to occur at the same point in the test (right before the final assertion)
test:
it "does something with things" do
#....
within('#dialog_box') do
click_button 'Save'
end
puts 'after within'
page.should have_content(thing_attrs[:name])
puts 'after assertion'
end
Final output:
after within
undefined|36|TypeError: Result of expression 'node' [undefined] is not an object.
after assertion
does something with things [pass]
How can I narrow down what is causing this? It makes test output ugly :)
I had a very similar problem, the error I was getting was:
undefined|0|TypeError: 'undefined' is not an object
In the end in order to figure out where it was coming from, I removed js files from application.js one by one until the error disappeared. Once I had narrowed it down, I figured out that there was, in fact, an undefined variable, which wasn't causing any issues and hence all tests were passing.
There might be a better way to do this, not really sure, but this approach worked for me. Best of luck.
Related
This is a mild annoyance I've noticed when running my rspec (v3.3.1) test suite.
For all test cases where I've used the be_success matcher, a newline is printed on my terminal. As a result, on running the suite, my terminal looks like this:
....*.................
.
.......
..
.
.......................................................F....T
Instead of
....*...................................................................................F....T
which is what I'd like.
I figured be_success is the culprit by running my suite with the --format d option and noticed that only tests that use be_success, cause a new line to be printed.
I'd like to know if there's a way I can get rid of this without having to replace be_success with something like have_http_status(200).
Thanks!
be_success does not normally print lines. All it does it call success?.
My guess is that you've got a puts in your success? implementation and/or in something success? delegates to. Perhaps from a past debugging session?
I have a pretty basic test that sometimes works, and sometimes fails with inconsistent error messages such as:
Failure/Error: Unable to find matching line from backtrace
AbstractController::ActionNotFound:
The action 'location_states' could not be found for LocationController
Or:
Failure/Error: select 'Nationwide', from: 'location_type'
Capybara::ElementNotFound:
Unable to find option "Nationwide"
Or:
Failure/Error: Unable to find matching line from backtrace
RuntimeError:
Circular dependency detected while autoloading constant LocationOptions
The AJAX callback that calls location_states to initialize the location_type dropdown is in an Angular scope, so I'm wondering if that's why there's this inconsistent behavior. I tried increasing Capybara.default_wait_time to 10, but that didn't seem to change anything.
The specific line that seems to be causing all of this:
select 'Nationwide', from: 'location_type'
since Capybara's select ultimately relies on find, I thought I wouldn't run into synchronization issues, but I guess I'm missing something here.
I'm using the phantom.js driver through poltergeist.
I'm having a similar problem using rspec, capybara, and poltergeist. Capybara is reporting that it cannot find an element that is clearly on the page. I use save_and_open_page and verify that it is there. Of course, when I put a "sleep 5" statement before my "page.find(:css, '#element_id')", well then the test passes.
New to Ruby, Rails and TDD. I'm using RSpec with Capybara and Capybara webkit.
Trying to test if a div element exists on a page.
Test Code:
require 'spec_helper'
describe "Login module" do
before do
visit root_path
end
it "should have a module container with id mLogin" do
page.should have_css('div#mLogin')
end
it "should have a module container with id mLogin", :js => true do
page.evaluate_script('$("div#mLogin").attr("id")').should eq "mLogin"
end
end
The first test passes but the second test fails with:
Login module should have a module container with id mLogin
Failure/Error: page.evaluate_script('$("div#mLogin").attr("id")').should eq "mLogin"
expected: "mLogin"
got: nil
Ran the JS in browser dev tools and get "mLogin" rather than nil.
Any ideas? Thanks.
find('div#mLogin')[:id].should eq 'mLogin'
See this from doc:
#evaluate_script
Evaluate the given JavaScript and return the result. Be careful when using this with scripts that return complex objects, such as jQuery statements. execute_script might be a better alternative.
evaluate_script always return nil, as far as I remember.
Anyway, your second test seems like is testing if capybara works, because your first test is enough.
One likely problem is that the have_css matcher supports Capybara's synchronization feature. If the selector isn't found right away, it will wait and retry until it is found or a timeout elapses.
There's more documentation about this at http://rubydoc.info/github/jnicklas/capybara#Asynchronous_JavaScript__Ajax_and_friends_
On the other hand, evaluate_script runs immediately. Since this is the first thing you do after visiting the page, there's a race condition: it's possible that it executes this script before the page has finished loading.
You can fix this by trying to find an element on the page that won't appear until the page is loaded before you call evaluate_script.
Alternately, you can wrap your call in a call to synchronize to explicitly retry, but this is not generally recommended. For situations like this, you're much better off using Capybara's built-in matchers. The evaluate_script method should only be used as a last resort when there is no built-in way to accomplish what you need to do, and you need to take a lot of care to avoid race conditions.
When I run my model specs and controller specs separately, it's fine. When I run them together, I get a stack overflow, literally :)
$ bundle exec rspec --fail-fast spec/models
........
Finished in 0.44274 seconds
8 examples, 0 failures
$ bundle exec rspec --fail-fast spec/controllers
..
Finished in 0.99339 seconds
2 examples, 0 failures
$ bundle exec rspec --fail-fast spec
F
Failures:
1) HerpController derp derp example
Failure/Error: Unable to find matching line from backtrace
SystemStackError:
stack level too deep
# /Users/jared/.rvm/gems/ruby-1.9.2-p290/gems/actionpack-3.2.1/lib/abstract_controller/layouts.rb:359
Finished in 0.02241 seconds
1 example, 1 failure
How do I even begin to debug this? Thanks.
Removing half of my specs at a time turned up the problem. I suppose this is an example of bisect debugging. Thanks to Frederick Cheung, whose comment suggested this approach.
For posterity, this was the problem.
include Rails.application.routes.url_helpers
describe "Attendee#next_page" do
end
Apparently, includes go inside the describe
describe "Attendee#next_page" do
include Rails.application.routes.url_helpers
end
I have a lot to learn about rspec. :)
You can either put a debugger statement in your code and debug that way, or just start using puts "got here" in the places of your code that you know are being run. I would suggest using something meaningful instead of "got here" too :-)
I'd start either with puts or raise statements at key points in your code so you can start to narrow down which line is causing the problem. Once you start getting close, you can comment out one line at a time to figure out which line the problem disappears with - as soon as you've got it down to one line, you can figure out what that line is doing that Ruby doesn't like.
In general terms of where to start, "Stack level too deep" is usually an infinite loop or infinite recursion problem - I'd imagine that there's something going on where a model is invoking a controller that's invoking the model, or vice-versa. No way to know for sure until you start commenting out lines, but any place where you've got function calls is going to belong on your suspect short list. Good luck!
Possibly you can get "Unable to find matching line from backtrace" error in case you are checking some var which wasn't initialised actually
In this example pay attention to var observation which is not initialised in the wrong snippet
wrong snippet
describe "GET index" do
it "assigns all observations as #observations" do
get :index, {}, valid_session
assigns(:observations).should eq([observation])
end
end
fixed example (line 3)
describe "GET index" do
it "assigns all observations as #observations" do
observation = Observation.create! valid_attributes
get :index, {}, valid_session
assigns(:observations).should eq([observation])
end
end
Sometimes we rely on using let as initializer, but forget to add it e.g.
let(:observation) {FactoryGirl.create(:observation)}
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.