Since the time I started using unit testing within my projects (specifically with NUnit & TestDriven.NET), the one thing you find very quickly, is that it’s not easy to test your presentation layer. Sure there are pricy products from people like Mercury, but I’m looking for something a little more affordable around NUnit’s price point (see: FREE).
Automated Web UI Testing
One of the most common suites I saw that’s used is NUnitASP. I attended a BOF at TechEd USA where it was discussed, but, like David Strommer, I didn’t get a feel like this was an ASP based solution… rather an HTML/HTTP solution. The tests you write seemed to only interact with the resulting HTML that reaches the client over HTTP… it makes no distinction between the different web technologies (static HTML, ASP, ASP.NET, JSP, etc). I’ve tinkered with NUnitASP and so far I’m not so thrilled. I’d like to see more of my tests integrated within NUnit. At any rate, the presenter, Jonathan Cogley, of the BOF session has some good NUnitASP helper stuff on his site as Darrell Norton pointed out recently.
While on vacation, I saw Scott Hanselman’s post about Ruby and Watir (pronounced wah-ter), where he went into detail about integrating them within NUnit… a very detailed post as well! Looks promising… and if Scott is sold as he stated in his post, then it’s definitely worth a look. Here are some links where you can get Rudy, available at RudyForge.
Automated Managed Web Application UI and Component Testing
When I say “managed web application”, I’m referring to something like SharePoint or MCMS 2002 which use IIS ISAPI filters to analyse, build, and render content based off the URL requests.
Another thing that has me challenged is testing your classes that extend objects from managed applications. As I mentioned previously above, if I was just interested in testing the presentation layer of my code in managed web application environments, I can just use an HTML/HTTP suite like NUnitASP, Rudy, or Watir. That’s fairly straightforward.
However there’s another case I’d like to test. What about the cases where you have an object that inherits another object that requires an HttpContext… but like MCMS, you use an extended HttpContext (such as CmsHttpContext)? Let’s take a Custom Placeholder Object as an example. When you create a custom placeholder, you can inherit the the BasePlaceholder object which has five methods to override. I’d like to be able to instantiate an instance of the object and run some tests on it. How would you go about it in this case? Well, I obviously can’t just run a test directly on the object because it needs to be run through the MCMS ISAPI filter.
One way you could test it was to manually (or programatically), build up a new posting, add some content, save it (and optionally approve it), then use one of the HTML/HTTP suites to test the resulting rendered HTML. But that’s quite a bit of work… I think it should be even easier.
Another approach is to seperate as much code as possible into another class. The CMS overloaded methods would then just be treated as wrappers calling the methods in your other class. It’s the same approach that many (including myself) use when they implement event handlers; you don’t put all your logic inside the actual event handler… your handler simply makes a call to a private method in the class. Then you don’t run any tests against your custom placeholder. Yes, it’s a risk you’re not taking into account, but it’s quite mitigated in my mind as long as you thoroughly test your wrappers. This method is working out quite well for me… so far.
However, it’s not nearly as nice as testing the object directly. So I blog aloud “what are other people doing in situations like this?” Anyone know how VS .NET 2005’s unit testing framework addresses this… if at all?