When I run rspec, is it possible to have capybara/selenium report any javascript console.errors and other exceptions back to rspec?
I have a whole bunch of tests failing, but my application is working when I manually test it. Without knowing the javascript errors that are likely blocking my single-page web app only during testing, it's really hard to figure out why the tests are failing.
I've looked around and haven't really been able to find a solution to this.
There's a code sample at the end of this gist https://gist.github.com/gkop/1371962 (the one from alexspeller) which worked very nicely for me.
I ended up doing this in the context of the JS tests I was trying to debug
Here is another way, currently working with Selenium and headless Chrome (should also work with Firefox).
Add the following to
spec/rails_helper.rb
, within theRSpec.configure do |config|
block and all feature specs withjs: true
metadata will display JS errors.The code is an adaptation of this.
I don't know if this will be of any help, but you could try switching over to thoughtbot's capybara-webkit driver. It's an alternative to Selenium that's headless, meaning it doesn't open a browser to run the tests. When I run my tests using this driver (in an RSpec+Capybara setup), all Javascript errors get printed inline with my RSpec output.
I've never tried switching from Selenium to capybara-webkit, so I don't know how feasible this is on an existing project. If you're not doing anything really fancy with Selenium, the transition might be pretty smooth. However, if you depend on being able to watch the tests running in the browser, or have some other specific need for Selenium, then my answer unfortunately won't be of much use.
You can find capybara-webkit here: https://github.com/thoughtbot/capybara-webkit
Getting it installed might be a pain, since you'll need the Qt4 library. If you don't already have Qt4 on your system, the build process can take a long time. For me, it was well worth the trouble. I much prefer capybara-webkit to any other solution I've tried.
This isn't pretty, but you could inject a script to direct errors into the DOM and watch for those changes via Selenium.
More specifically, inject a script into each page which overrides
window.onerror
orconsole
such that errors append the information to some hidden node you've injected into the DOM. Then, via Selenium, periodically check for and empty the contents of that element, printing the emptied data to the Java console.I'm doing something similar to Leo, but including the browser logs as part of the test failure message: