#391 Testing JavaScript with PhantomJS pro
PhantomJS allows us to test JavaScript without going through a browser window. Here I show how to do this using Capybara and Poltergeist. I also give some tips on handling database transactions and skipping javascript tests.
- Download:
- source code
- mp4
- m4v
- webm
- ogv
Thanks for this episode.
In the scrolling test case, I didn't catch how it works under the hood. As I understand it correct, the content "Order #11" is not present immediately after calling
page.evaluate_script("window.scrollTo(0, document.height)").Does this command wait for the content? If so, how should I test that message "Fetching more orders..." is showed (just for a while)?
Capybara automatically waits for the content to appear. There's a default time it will wait that you can override. I'm not sure how you would reliably test for the "Fetching more orders.." part though. I'm betting that you would run into instances where that disappeared before Capybara could verify it was there.
good
Thanks Lukas
In case anyone is curious on how this performs against Capybara-webkit as the driver, I found it to be ~10% faster. Additionally, the error messages are much more helpful.
for me Capybara-webkit is around 10 % faster than Phantom and capybara-webkit reports fewer false positives..
Hey Ryan, great episode. Have you tried capybara-webkit? How does PhantomJS compare to this gem? We've been using it extensively and it works pretty well.
The advantages I've noticed for poltergeist over capyabara-webkit as the javascript_browser for capybara are:
PhantomJS 1.7 doesn't depends on QT as well.
like Samnang already said, it does not depend on QT.
For us it was quite a pain to get Capybara Webkit running because of the QT dependencies. I can also remember some compilation issues on CentOS.
So Poltergeist came as god sent. It is a nice small package that is "just working".
If you have Capybara Webkit running and are happy with it you probably do not need to switch.
I've made some short testing and capybara-webkit is still around 20% faster in our use case. I suggest you try it for yourself and see, that's a matter of minutes or hours if run longer tests to have better metrics.
Great work again Ryan.
I starting using this on my latest project and it rocks. However beware of bug related to following relative urls.
Phantomjs is unable to follow a javascript redirect (i.e. window.location.href = XXX"
it throws a "Not allowed to load local resource" error.
AS a quick and dirty i just changed the relative url to full url in the affected code and that fixed the problem.
Hope that helps anyone that might encounter this issue.
Here is link to recent post with some specific issue tix
https://groups.google.com/forum/?fromgroups=#!topic/phantomjs/fVBd3kGOQh4
I´m getting an Dead::Client error with phantomjs. I think it´s an issue when using fontawesome webfonts. Has anyone a solution to that?
https://github.com/jonleighton/poltergeist/issues/44
https://gist.github.com/3996516
https://gist.github.com/4003597
Found a very weird bug, maybe it is actually poltergeist related. While I haven't had time to fully investigate it here is what happens:
boom, after the second visit I find that that I am logged out, current_user is nil.
If, on the other hand instead of doing the second visit call I use respective click_link sequence everything works like a charm.
I did just a little bit of testing, but for me PhantomJS was about 20% slower than Capybara-Webkit.
You don't end up with the QT dependency though... So that might be worth its weight in gold to some.
I get this error when i try to run the specs:
What could that be for?
This doesn't work for me. All "page.should have_content" assertions fail under this stack. And when I do a "save_and_open_page", well, there's no styling and no JS. In other words, there's nothing available from the asset pipeline. It has been a real struggle. 5 12-hour days straight trying to set up this testing stack. What a waste.
FactoryGirl fails with:
undefined method `error_field' for nil:NilClass
No stack trace given, naturally.
I was getting a "PG::Error connection closed" message. Here is the solution:
For Postgres users who are also using Spork, the Plataformatec blog solution will not work as stated. In other words, if you put the shared_db_connection.rb file in your spec/support directory, you will get a PG::Error connection closed message. Leave the file in spec/support but remove this line:
ActiveRecord::Base.shared_connection = ActiveRecord::Base.connection
And instead put that in your Spork.each_run block in your spec_helper.rb file.
H/T nicholasmott from the comments section on the Plataformatec blog.
This is a life saver! Thanks for the tip.
Does anybody know of a way to run your js specs at the and of the suite?!
Hiya, I’m really glad I have found this info. Nowadays bloggers publish only about gossip and web stuff and this is actually frustrating. A good site with interesting content, this is what I need. Thanks for making this site, and I will be visiting again. Do you do newsletters by email?