Make poltergeist tests easier to debug

[stardust66]

This should be incorporated into a guide. By using the :poltergeist_debug(#432) driver, you can write page.driver.debug statements in the cucumber step definitions to have it pause and show a browser window with a web inspector hooked up to the tests, in which you can see javascript errors and the DOM. See my PR for more information.

Read more:
https://github.com/teampoltergeist/poltergeist#remote-debugging-experimental
http://www.jonathanleighton.com/articles/2012/poltergeist-0-6-0/

[DeeDeeG]

Getting a full devtools up seems powerful and flexible. It also takes a bit of learning to know how to activate this, and it's a lot of steps to then actually change and run the tests manually to get the devtools up for debugging.

The second link you gave has a section about just "re-raising" the JavaScript errors in PhantomJS as errors in the overarching test framework (Capybara, so also Cucumber or RSpec tests that depend on Capybara...)
http://www.jonathanleighton.com/articles/2012/poltergeist-0-6-0/#javascript-errors

So, from poltergeist's GitHub Readme:

• :js_errors (Boolean) - When false, JavaScript errors do not get re-raised in Ruby.

We should set :js_errors => true. Intuitively I think it should be on by default, so investigating whether that is already working, or how to get it working, would be worthwhile IMO.

I think that would be more seamless, and quicker, but less powerful than a full devtools/remote debugging. I can't really figure out what this next paragraph of the post means, but it sounds like that nice :js_errors feature gets disabled if :inspector => true. Again, it would be worth testing out these options before merging, IMO.

If you setup Poltergeist with the :inspector => true option (see the docs for details), PhantomJS will get set up in remote debugging mode. Note that due to internal WebKit reasons, we can’t report Javascript stack traces in this mode (but that’s okay, because you can see the stack traces in your inspector window).

Looking forward to trying this out over the next couple of days and/or as I get time...

[stardust66]

Your intuition is correct that :js_errors => true is on by default. See this line in the travis logs of my map detail PR. In those particular tests however, the stack trace wasn't very helpful. I don't think we have to worry about not having them when remote debugging is turned on because we get the javascript errors in the web inspector instead.

[DeeDeeG]

I think trying is the only way to find out, so we'll just see how it goes.

EDIT: Posted too early, meant to add another sentence:

My point was just, what if the JS errors being easily (lazily?) viewable is more worthwhile? But honestly we won't know what's worth what or which is better until we've tried both.

[stardust66]

I think it's a good idea to write about this in the Wiki. Where would be a good place?

[DeeDeeG]

Good idea. I'd say this could be added in articles about the existing testing frameworks:

https://github.com/RefugeRestrooms/refugerestrooms/wiki/What-is-Cucumber%3F-What-is-Test-Driven-Design%3F

https://github.com/RefugeRestrooms/refugerestrooms/wiki/What-is-RSpec%3F-How-do-I-create-unit-tests-for-Ruby-code%3F

Or in its own, new article. If you do make it its own article, that article can get a brief mention and a link from the articles about testing frameworks. I'd recommend that approach. But whatever is readable and discoverable are kind of two of the guiding principles of the Wiki as of yet.