Skip to content

HOWTO dev debug_Cucumber_with_Selenium_misc

Jump to bottom
steveoro edited this page Jan 16, 2021 · 1 revision

HOWTO: Debugging front-ends with Cucumber/Capybara & the Selenium driver

...And other Cucumber-debugging specific quirks

Node visibility & feature specs

What: Selenium, as a web driver for Cucumber, replicates basically a feature-complete headless browser, so it enforces visibility constraints on all nodes. If a node is not visible or is overlapped by another, triggering events on hidden or partially hidden content won't be possible.

How: Just replicate all the specific UI steps an actual user would do to reach or reveal the content you wish to interact with.

All those "shortcuts" you took with the Poltergeist driver cannot be used anymore: if a node is even partially visible or still transitioning from hidden/disabled to shown/enabled, the event triggering may not work.

Make sure the node is in the expected state if it's critical for the next steps (as when a dialog needs to be completely shown before clicking on it, or when a section is animated on pop-up).

Clueless blank page during debugging

What: You obtain a blank page (or a blank screen shot) after a specific request.

This usually due to errors happening during the callback chain of the controller action involved.

The callback chain is built up, starting from all the before filters and associated calls.

For instance, you may use external API calls in the action implementation or from inside the action's filter(s).

Any RestClient request that needs an external endpoint surely needs to be mocked during the tests (if the actual servers aren't available to the Selenium runner instance).

Any other "implied" events, like Pundit or CanCan policies or custom Devise checks, or any other custom gem that may halt or redirect or alter the callback chain due to failure.

How:

  1. Reconstruct precisely the call chain and inspect the possible callback/action failing.

  2. If it involves an external API, either pry into the point of failure or reconstruct the failing sequence from the debug console; then, from the debug console, invoke RestClient with the alleged culprit request and see if the API mock is in place. Inside the console you should be able to get & see the actual error message from the call and you'll be able to fix the call & test manually a new valid stub for it (be it, using a new or different WebMock.stub, if any edits are required).

  3. If it involves a policy of any kind redirecting or altering the callback chain, pry into the failure as above, reconstruct & call the alleged Policy or strategy check to see if it allows the call to proceed. If this is indeed the case, it's also a red flag for an improved test coverage for the alleged culprit object (thus, please, fix it by also adding relevant tests to the Policy or Strategy object).

"KeyError 64" (key not found: 64 (KeyError))

What: This Capybara error may result from an event triggered on a hidden, partially visible or out-of-page node.

Although Capybara is smart enough to bring inside viewport "focus" fully visible nodes that are rendered "outside of the visible page", even those may trigger this error.

Depending on current CSS styling, layers and actual page rendering, you may have commanded to click on a node when not immediately visible, although visible "somewhere in page".

How: If the node is indeed visible, just scrollTo the bottom or top to the page to make it visible inside the current viewport:

  • Scroll to top of page via JS: page.execute_script('window.scrollTo(0, 0);')
  • Scroll to bottom of page via JS: page.execute_script('window.scrollTo(0, 10000);')

Most of the other occurrences are due to a too short delay before the actual triggering of the action or event.

Many dialogs have, in fact, a small transparency animation during show that requires a small sleep before having their nodes considered as "100% visible".

In other less common cases, this can be due to some unexpected events triggered either by your JS code or by any other JS libraries used. This is usually a "red flag" for something that is not properly setup or initialized in that part of the front-end you've just tested.

Failure to log-in

What:

Cucumber can't seem to replicate a successful User login, even though in other environments other than test everything seems to work as expected for the same dataset.

We'll be ruling out database issues for this one, assuming that the test DB has already been properly setup with the correct fixtures or whatever else is needed.

Then, you conclude, this is just session-related.

How:

Check config/initializers/session_store.rb (if you are ever using one). It should be something like this:

Rails.application.config.session_store(
  :cookie_store, # (Default store)
  expire_after: 120.minutes,
  key:          Rails.env.development? || Rails.env.test? ?
                '_goggles_v7_session' : '__Host-goggles_v7_session'
)

Using the __Host prefix for cookies enforces in the browser a secure connection for handling cookies, including serialization.

When not on an HTTPS connection, the prefix for the session store forces the browser to prevent (disable) the ability to store secure cookies, unless the host serving the connection does not also abide to enforcing the secure transport layer.

Either do not use the __Host prefix inside the test environment or install a local HTTPS certificate even for localhost and enforce HTTPS usage in the whole Rails application.

(Keep in mind that enforcing TLS/SSL is not always easily doable, especially when the app is behind a Proxy.)

Clone this wiki locally