Wolfmans Howlings

A programmers Blog about Programming solutions and a few other issues

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 &lt;b&gt; 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.


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...


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!

Posted in Rails,RSpec  |  Tags rails,rspec,escapinghtml  |  4 comments


  1. zubari said on Wed Jul 18 20:45:59 -0700 2007
    You might find it useful to break down that rather large specification into separate blocks for each of the models you use so that it is easier for you to identify problems if they do occur. In its current state, if you DID forget to escape the html, it wouldn't be obvious where the problem was occurring.
    A possible strategy would be to mock the models in a "before" block, and then add the stubbing afterwards in separate behaviours.
  2. wolfmanjm said on Wed Jul 18 21:52:25 -0700 2007
    Thats a good suggestion. The reason it is in one behavior is there is only one render call, and I try to test the render as it would be called in real life with lots of input.

    However for the purpose of this specific test, you are right it would be easier to track down the problem if I tested each object separately and called the render three times instead of once.

    However it wasn't really hard to track down the problems when the `puts excerpt...` was enabled as it showed exactly where the error was.
  3. Tony said on Wed Aug 01 11:33:53 -0700 2007
    So this still requires a setup and a spec for _every view_. Could get quite complicated for heavier pages, as the home example demonstrates.

    Would be nice if HAML just escaped everything on its own in the first place.
  4. Henrik N said on Mon Jan 14 07:59:41 -0800 2008
    Thanks for the idea – implemented something similar.

    You can probably do something like this to get around re-implementing excerpt:

        puts "Unescaped user data here: " + response.template.excerpt(response.body, "<b>")

(leave email »)