Help testing helpers

Posted by rick Wed, 08 Feb 2006 21:31:00 GMT

Ruby on Rails is big on testing. There’s support for unit testing cooked right in—every time you create a model you get the unit testing framework built for free—just fill in the blanks. Similarly, whenever you create a new controller, you get the functional testing framework built for free—just fill in the blanks. Seems like view testing (with Selenium and OpenQA) is moving forward, and I wonder if some sort of automated support for those won’t come from the Rails framework itself soon…

That said, there’s very little talk about testing helpers—those bits of Ruby code that are made available for use by the view, but which aren’t in the templates themselves. Helpers aid reuse, and are a valuable use of Ruby behind the template.

Certain helpers can be tested with test/unit, just like unit tests for models. Some helpers, though, call functionality in the view libraries: a really common idiom is to provide various foo_link() methods that will generate links to certain types of objects. Rather than repeating the same detailed ActionView link_to() call everywhere, the code is factored out to a helper method which assembles the appropriate information and calls link_to() for you. Then you’ve got a single point of change whenever you want to change how comment links, story links, user links, whatever, behave.

Testing this sort of code should require a functional test, since you’ll actually want to have the view instantiated. There’s seemingly zero documentation on how to do this, and, checking around on some existing Ruby projects, I see people writing these sorts of helpers, but I see noone actually testing them.

We’ve jumped back for a moment and are relying on “stub” code to allow us to get a primitive, but less than ideal, test of our link helper (and other similar helpers that call ActionView functionality). We’re now looking for guidance from the Rails community.

To that end, we’ve posted Rails ticket #3775.

Comments

  1. Peter Merel said about 5 hours later:

    What you’re looking for is WATIR (http://wtr.rubyforge.org/).

    We too tried Selenium first but the thing was flakey for us in driven mode. And we needed it driven. After too much pain we figured Selenium driven suffered internal race conditions; not something we wanted to muck out.

    WATIR saved the day. Caveat is it presently drives IE only. My team is Linux-based so we’d dismissed it, but when push came to shove we turned our WATIR into WINE (http://www.winehq.com/).

    Sorry about that.

    Anyway here’s how:

    1) Install the latest WINE. You shouldn’t care if your distro already has wine. Get the very latest stable packages. Have wine-utils do a clean install of IE6 on top of that.

    2) Install Windows Ruby over WINE. Your Linux Ruby won’t run WATIR because it can’t require Ruby’s win32ole module. The Windows installer’s a one-click once you figure where to put it in wine.

    3) gem install watir on your wine ruby.

    4) Go run the watir unit tests over wine ruby. They should all pass.

    So far watir/wine is making us very happy. Unlike Selenium there are no XSS issues and HTTPS works fine. If we could test cross-browser it would be perfect.

    Which is what’s promised for the next version …

    There’s also an excel-driven front end for WATIR called WET. The WATIR equivalent of FIT. But it’s not very Rubyish and the docs turned us off it, so we’re not troubling at this point.

    Also there’s a test recorder called Watirmaker. Not very mature and we haven’t yet tried to run it over WINE. We read that the developers are making a pure ruby version though so we’ll see …

  2. Peter Merel said about 6 hours later:

    Um, on point 1, I mean don’t use your distro’s wine if it has one, use the latest.

  3. rick said 1 day later:

    Peter,

    Thanks for the detailed advice. We’re right on the cusp of doing some browser-level testing ourselves (as you can probably tell from the babbling about Selenium, etc.). There are two things I’m interested to hear: (1) that you successfully got working the same sort of automation of IE that I’ve been thinking about doing (I was worried we might have to shell out for VMWare, or worse, do some pure-windows automation—we’re a primarily Linux development shop, and we don’t consider Windows to be an automatable server environment); and (2) that Selenium has stability issues.

    We’ll have to look a bit closer at Watir vs. Selenium, but we definitely are glad for your tips.

    Best,

    Rick

  4. Jimmy said 40 days later:

    I came across this page since I had wanted to do a similar thing. It’s interesting that the comments you got back were for testing from the browser pov, since I find that un-necessary for what we’re trying to accomplish.

    The controller helper module is very useful for reuse of view/controller related code, and it seems natural to create tests in the controller for it. Adding on another tool to test the websites in a specific browser is another problem all together.

    So, being that this post is 40 days old, did you come to a solution? Also, I noticed that they closed your ticket, siting that it’s a duplicate. Could you post a link to that ticket? I’m sure it would help those test-driven developers out there :)

    Thanks in advance, ~Jimmy

Comments are disabled