Wolfmans Howlings

RSpec testing views for escaped HTML

Posted by Jim Morris on Fri Jul 06 18:22:57 -0700 2007

For my social networking site snowdogsr.us I decided to escape all user input that gets displayed. I know people like to trick out their profiles with HTML but I want to avoid the various hacks that it allows.

So thinking I had done a good job of using h everywhere I output user input fields, I decided to see if I could actually test this with RSpec view tests.

I recently switched to RSpec for my testing needs, its cool :)

One thing it does is isolate the various things for testing using built in mocking, and views can be entirely tested standalone without accessing a model or a controller.

So how would it do testing for escaped user input I wondered?

Very well actually.

An example is worth a thousand words, so here is my RSpec for my home page.

BTW I found about 4 places where embedded HTML in user input was bleeding through, so it was well worth the effort.

So this goes in spec/views/home/home_spec.rb...

Its quite complex as the home page renders a lot of summaries of the various lists I have.

First I mock the models that are called, and stub out the calls that are made to them. I force them all to return an embedded <b> which I don't use anyway, and with the new CSS oriented web styles shouldn't be used in HTML anyway.

Then I just test that <b> does not appear anywhere. If I have correctly used h to escape all the inputs then it should be rendered as <b> instead.

The response.should_not have_text(/<b>/) should do that test.

One cool thing is the mocking will tell you if any new inputs (ie calls to model attributes) have been added, or if you have forgotten any. So this should keep you honest in the future if you add new attributes that need escaping.

The

assigns[:new_stuff] = @new_stuff
assigns[:top] = @top
assigns[:new_pets] = @new_pets

Sets the assigns to the variables that my view uses,simulating what the controller would pass in.

The mock_model calls at the top also use a shortcut to define all the attributes that get called, and what they return. You can also explicitly do this...

@post.should_receive(:comments).and_return(@comments)

If you read the RSpec docs you can see that you can also test for parameters passed in, how many times it is called and various other nice things.

I added this snippet taken from the rails helpers to aid in finding any errant HTML that bleads through. (I'm not sure how to call it from the RSpec so I just copied the code into a private method).

and you can see the call that shows me where the errant <b> is...

puts excerpt(response.body, "<b>")

I also have some setup code that handles the login and log out mocking, but I'll leave that for the end user to sort out ;)

So I think this will make sure that now and in the future this particular view will not bleed user input HTML.

Once I did the complex one above the rest of the views were much easier and quicker to implement. Here is an example of a really simple one...

Couldn't be much simpler, but I found one place where I was not escaping the HTML!