Image Credit: PixelPlacebo via Flickr and Creative Commons

Unit testing is good; test driven development is better.  As Knuth once famously quipped “Beware of the above code. I have only proven it correct, not tested it.” There really is no substitution for good, solid testing.

Unfortunately, at least in C#, webpages don’t like to be unit tested.  I approach this post with an uncomfortable realization that I am about to lay out the issues and problems I’ve had while the solution I am presently using is far from satisfactory.

There is a right way and a wrong way to undertake a lot of unit testing.  If you want to learn about that, I recommend this post by Ryan Hagan as a great jumping off point.  My problem is not in writing good unit tests, however, so much as having a place to write them.

Axiomatic truth of Unit Testing: Your test code should exist in a different place than your production code.  This just makes good sense.  You don’t want to publish your tests every time you push code out the door and, since you want all of your published code to be tested you don’t want to have to write tests for your tests.  In C# the way one generally accomplishes this is the creation of a separate test project within the current solution.  That way the solution contains both your code and your tests.

Now generally, when you’re writing tests for C# this isn’t a big deal.  Since your project gets bundled up every time you build you can add a reference to the Test project that points at your main project; that way, the test harness knows what to make of all the custom types and whatnot that your various tests will have to evaluate.

This does not work for webpages.

When C# builds a webpage there’s no handy-dandy compiled thing at which to point your test code.  That means your test code has no idea what to make of any custom objects you’ve created and that makes any meaningful testing pretty much impossible.  Consider the following short example:

public void CreateTest()
        {
            string WidgetName = string.Empty;
            Widget expected = null;
            Widget actual;
            actual = WidgetFactory_Accessor.Create(WidgetName);
            Assert.AreNotEqual(expected, actual);
       }

In this example, “Widget” and “WidgetFactory” are both custom types.  C# has conveniently generated an accessor for my Factory but it has no reference to my main project and thus doesn’t know what a Widget is.  Consequently, this test won’t compile and I can’t run it.

There is a work-around solution I’ve found wherein I publish the Main Project and then create a reference from the Test Project to the published AppCode.dll file.  This works but requires that I publish the DLL every time I wish to re-evaluate my source code which makes the entire testing process prohibitively time consuming.

My suspicion at this point is that what I am trying to do is in fact neither possible nor recommended and that unit testing of a C# webpage should be accomplished by creating a sharp distinction between the interface and presentation layers, testing the presentation layer traditionally and then using interface testing suites like Watir.  This seems the sort of thing that should be verbosely stated somewhere if it is, indeed, the case.

Update

As per Ryan’s suggestion below and some other feedback I’ve gotten I am moving much of the logic code out of the project and creating a project-level distinction between the interface and the presentation layers of the application.  This should allow me to more sanely test the presentation layer and leverage Watin in to handle the interface testing.

It’s not the sort of separation recommended, but the architecture on this particular system is fairly dated and a full out re-factoring is out of the question (for now).

As it’s conspicuously missing from many other write-ups I’ve seen I’ll say it here.  You can not meaningfully test anything except the interface of a C# web project.  If you want to test your code, move it into a DLL project and allow your web project to call that DLL.  Ideally the Web project should be as thin as possible.

How do you user test this?

Most of the blogging I’ve done in the past has been political and thus I really haven’t had an opportunity to try to post much in the way of source code in a blog.  Once I got Nephandus up and running on WordPress, however, I thought I’d have a shot at it and thus posted a short article on my experiences with C#’s serialization quirks.

To illustrate a specific point I included a brief snippet of C# code which WordPress promptly turned into an illegible mess.  The web is a notoriously difficult place to display source code and thus I set off in search of a WordPress plug-in that would allow me to do so without too much thought.  Several days, a dozen plug-ins, and a string of curse words that would make a sailor blush with shame, I have a solution.

There is no shortage of syntax highlighting plug-ins available, but the support for their instantiation is practically non-existent.    Nephandus is running a number of plug-ins, none of which required much more than a few mouse-clicks to install and configure yet this particular task proved more difficult and involved than anything else I’ve done with WordPress.

The more I thought about this frustration the more I realized that this is an ongoing problem in the software development industry.

When developers buid a word processor or an email application they spend (or they should spend) a fair bit of time working out where users will intuitively look for certain basic functionality.  Tools, options, and commands should be where the user expects them to be; that saves time and cuts down on support costs.  We can test and evaluate that design by asking people who are totally unfamiliar with the product to find those sorts of functions and watching what they do.  It’s a system that works well because, familiar with the product or not, everyone has a basic grasp of certain tasks like writing or arithmetic.

But how do you do that kind of testing with an IDE?

The people who use IDEs are, pretty much by definition, super-users.  At the very least we can expect them to have a high level of familiarity, if not with the interface itself than with the thing the interface manipulates – code in a programming language they know.  These users have very specific ideas about where things ought to be which are based, not on intuition but where they were in some other IDE that they learned.  Because the population of knowledgeable coders is small and the number of IDEs they develop on is also small, it’s likely that they’ll bring some of their preconceived notions into user testing and that those notions will persist through the testing process.

Neophyte users aren’t terribly helpful because while they’re learning the interface they’re also learning the language and thus don’t know enough to evaluate the more powerful aspects of a product.

How then do you test the usability of a new interface when that interface’s intended users are a small, niche population often with preconceived, conflicting, and sometimes nearly religious notions of how the interface should look, feel, and act?

That isn’t a problem that WordPress plug-in authors really need to worry too much about – at least not if they’re giving their work away for free (beggars can’t be choosers) – but those of us who make specialty products for high-end niche professionals need to find a way to tackle the problem lest we find ourselves unable to change a 30 year old catastrophe of a design because it’s what everyone knows and expects.