Several of the reports that the app that Joey and I are working on will be generated via HAML to be displayed in the app, for the users. The generated content will end up being HTML, but starts it’s life as HAML markup – our preferred markup for Rails apps. It’s easy to generate HAML into HTML, in code:
We store the result of this in a model that is persisted in our database. Later, when a user requests the report, we pull the generated HTML out of the model and put it on the screen, so that it can be rendered in the user’s browser.
All of this works quite well and is easy for us to do. However, we ran into a problem when trying to verify the content from a Cucumber feature. We used this to try and match the generated HTML content from our model, with the content that was shown on the page:
But it didn’t work – we got errors saying that it couldn’t find the content we wanted even though we could clearly see the content on the page via our browser. I’m not entirely sure why this doesn’t work, honestly. I’m assuming that Capybara is doing something behind the scenes that causes the text it finds on the page to not be the same as the text we supplied – though I can’t say for sure.
After a significant amount of trial and error, writing out various bits of data to the console via Cucumber tests, and reading through a lot of Capybara and HAML documentation, we couldn’t get it to match with Capybara at all. So, we dropped back down to RSpec for the matcher.
I’m still not sure why, but this does work. We’re using Capybara to find the <body> tag of the page and load all of the content from the body via the .text attribute. Then we’re using RSpec’s “include” matcher to verify the content we pulled from the model was found in the raw text of the body.
It took significantly longer than we wanted, but we finally got the test passing. In the future when we are generating HTML from HAML, we’ll know to skip the Capybara matchers and using RSpec’s matchers within our Cucumber tests.