Scott Hanselman's Computer Zen - NUnit/Watir/Ruby Test Integration

First time here? Check out the site's "greatest hits" or read a post from the archives. Feel free to leave a comment or ask a question, and consider subscribing to the latest posts via RSS or e-mail. Thanks for visiting!

« Clicking a JavaScript Dialog using Watir... | Main | First Person Shooters on the PSP »

NUnit/Watir/Ruby Test Integration

Posted in ASP.NET | Ruby | Watir | NUnit

Travis Illig took my NUnit/Watir integration POC and ran screaming down the street with it and has released his code on CodeProject. There are also some other integration projects in a similar vein going on that I'll post about later.

Travis' solution is clever in it's use of attributes. It does everything automatically that I did manually with resource extraction. The easiest way to grok it is to look at a sample NUnit test you'd write:

using System;
using NUnit.Framework;
using RTE = Foo.RubyTestExecutor;
 
namespace Foo.Test 
{
    [TestFixture]
    public class RubyTestExecutor 
    {
        [Test(Description="Verifies you may run standard NUnit-only tests.")]
        public void NUnitOnly_NoRubyAttrib()
        {
            Assert.IsTrue(true, "This NUnit-only test should always pass.");
        }
 
        [RubyTest("Foo.Test.Scripts.RubyTest.rb", "test_Valid")]
        [Test(Description="Verifies a valid Ruby test will execute.")]
        public void RubyTest_Valid()
        {
            RTE.ExecuteTest();
        }
 
        [WatirTest("Foo.Test.Scripts.WatirTest.rb", "test_Valid")]
        [Test(Description="Verifies a valid WATIR test will execute.")]
        public void WatirTest_Valid()
        {
            RTE.ExecuteTest();
        }
 
        [RubySupportFile("Foo.Test.Scripts.supportfile.txt",
            "supportfile.txt")]
        [RubySupportFile("Foo.Test.Scripts.SubFolder1.supportfile1.txt",
            @"SubFolder1\supportfile1.txt")]
        [RubyTest("Foo.Test.Scripts.RubyTest.rb",
            "test_RubySupportFile")]
        [Test(Description="Verifies Ruby support files can be extracted.")]
        public void RubySupportFile_Valid()
        {
            RTE.ExecuteTest();
        }
    }
}

It's the ExecuteTest() of course that does all the heavy lifting by walking the call stack looking for Attributes and acting on them. Check out his article and get involved.

Posted at 2006-01-13 05:26 PM by Scott
Comments [2]
Permalink

Tracked by:
"Scott rocks" (Keyvan Nayyeri) [Trackback]
http://sjefford.wordpress.com/2006/01/16/test-from-feeddemon/ [Pingback]

Friday, January 13, 2006 5:56:06 PM (Pacific Standard Time, UTC-08:00)

It's starting to look like I have nothing better to do today than comment on Scott's posts... :)

To quote your original post, "We talked about adding [WatirTest] attributes or extending a new WatirTestCase and even a whole new series of Assertions, but we didn't see any reason to be tricky, other than to be tricky. We opted for simple simple simple."

And it was simple. And effective. And easy to integrate in any other type of class, like non-NUnit classes. I actually wrote a service to monitor website availability (and page me if there's trouble) using it.

While I admire Travis' code for its cleverness, I still prefer the Hanselman method.

Cam

Thursday, January 19, 2006 8:11:46 AM (Pacific Standard Time, UTC-08:00)

We've been working on this type of thing for a little while. We tried to work with NUnitAsp, but NUnitAsp doesn't really fit what we want to do, mainly because it requires a green-field approach. That is, its really designed for web server controls. That's not practical for several reasons, not the least of which is the fact that you can't go back and reimplement legacy sites just to make your testing framework useful.

We use SgmlReader to parse the HTML (giving us a valid XML doc), and then use XPath expressions to validate it. All of this is done within the NUnit testing framework.

This is a really nice way to go, IMO, b/c you don't need to learn a new programming language (like Ruby), and you can still use a test-driven development approach.