It's Bruno

Hey, I'm Bruno 👋

I'm a software engineer with experience in design, development and testing of web-based applications.
You can find me on twitter or write an email.
November 9, 2016

Debugging feature specs

Debugging feature specs can be a frustrating experience. However, there are a couple of tricks that can make your debugging session a bit better, at least if you’re using capybara-webkit to run them.

Today, I was debugging a failure with the classic expected to find text 'my text' in 'this content'.

Checking the interface

As usual, the first step is to add a save_and_open_page statement to see what’s happening on the page. I remember getting a lot of leverage out of learning save_and_open_page. Something about being able to see what’s up is super valuable. This is what I saw:

That seemed like a pretty honest error to me. It was trying to find some text inside an empty modal.

Checking the JavaScript

I know that the content of this modal is rendered with React, so I suspected this could be a JavaScript error issue. The error was not happening locally, so it was something specific to capybara-webkit.

Just like you can use save_and_open_page to see the page, you can use page.driver.error_messages to check javacript errors inside capybara-webkit. I usually combine it with rspec expectations, so that the spec will fail if there are any errors. This is as useful as save_and_open_page in this world of JavaScript we live in.

Unfortunately, that is as far as it goes. There’s no way to see the backtrace.

After some searching I learnt that Object.assign and other ES6 goodies are not available on capybara-webkit. That code was running inside a React component, that’s why the modal was empty.

Adding a polyfill for Object.assign from MDN was the way to fix the spec until we get our migration to Webpack finished.

I hope using save_and_open_page and page.driver.error_messages helps you too!

Cheers 🍻

Made in São Paulo ☂️