Steve Wilkes

Why Automated Tests Are So Great

Steve Wilkes — Sat, 02 Mar 2013 09:52:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2013/03/02/automated-integration-unit-testing-advantages.aspx

I've recently done work at a company where there are no automated tests, and tests aren't part of the culture. I've been writing tests for so long now that it's jarring to consider working without them, so I've gone ahead and written tests for my part of the work. As I've done so it's really brought home the advantages of writing tests, and I wanted to list them out.

Tests Make Your Code Work

The earlier you write a test for a piece of code, the sooner you'll find yourself stepping through it, double-checking that and how it works. Working with code through tests is a unique experience, and things occur to you when you're stepping through a class that won't when you're reading through it. What if that variable turned out to have that value? What if that resource turned out to be unavailable? Watching your code go through its paces brings home the fact that it's going to be part of a functioning system with real users one day, and makes you consider if it does its job properly.

Tests Give You Easy Entry Points To Diagnose Problems

If something goes wrong in a particular part of your system, tests give you a way to access that part without going through the various layers that usually sit between it and the outside world. Without tests you have to crank up the entire system and work your way from the user interface to the situation that caused the error. That could include getting a user into a particular state or entering a particular combination of data - do any of that even a little bit wrong and you can easily find yourself no closer to a solution, proclaiming that "it works on my machine". Worse still is if the error was caused by something transient, or a quirk in a third party system only triggered by certain circumstances - with tests you can easily stub out components and reliably simulate that behaviour so you can check how your system deals with it. Without tests... well... good luck with that.

Tests Guard Against Other People's Changes

A colleague working without tests reported the other day that he'd spent most of a day trying to figure out why part of the system he'd written had stopped working. He'd been sending the same data to a third-party service all along, and up until that morning it'd always worked; he now wasn't sure if something had changed with his setup or what he was doing, or something had changed with the third party. Tests would have stopped this problem before it got started - he would have had a failing test to go to telling him what had changed.

Tests Are Specification

You have a specification which says in circumstance ABC the system should perform action XYZ - does it? Sure, you stepped through it those times and saw it do XYZ, but a lot has happened since then - does it do XYZ now? Tests are an executable specification of what your system does. Not what it's supposed to do, but what it does. Tests are the only specification you have which the code definitely fulfils. You probably have a Word document which says how your system is supposed to behave, but your tests tell you how it actually behaves. In every area of life, you only know what you can demonstrate - tests are a great way of demonstrating what your system does.

Tests Are Documentation

How are the classes and subsystems in your system used? What inputs do they expect? What outputs do they give? Do they have any quirky behaviour? Do they throw exceptions or returns nulls or empty collections? That third-party library you're using to validate bank account details - does it say account number 111111 with a valid sort code is valid, or invalid? You can write comments, Sandcastle comments, Word documents and make UML diagrams all you want, but your tests are the only documentation you can rely on to be accurate. If code changes, passing tests have to change with it - comments, documents and diagrams don't.

Tests Are Insurance

You put an application live and move on. A few months later you revisit it to add a new feature - without tests, how easy is it to tell if your new feature breaks any of your old features? This is a few months down the road and your familiarity with the existing system has faded, so your intuition isn't going to help you as much as it once did. This is another area where tests pay huge dividends - if your new feature breaks an existing one, your tests will let you know. I've added to and refactored code on a well-tested project where I've genuinely had no idea (and put next to no effort into figuring out) if it would break something - safely insured that if it does, my tests will tell me. Without tests you're stepping on eggshells whenever you need to change existing code.

...and that's why tests are so great. I've been working with them for so long now that it baffles me how anyone writes anything non-trivial without them. Getting used to writing tests takes some discipline and effort, but it's repaid many times over - if you don't write tests, you owe it to yourself and your team to start.

A Generic, IDisposable, Unit-Testable, Error-Handling WCF Service Client

Steve Wilkes — Sun, 17 Feb 2013 12:23:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2013/02/17/generic-idisposable-unit-testable-error-handling-wcf-service-client.aspx

I recently reused my generic, disposable WCF service client, and made some changes to make it simpler to use and easier to unit test. The original client was used like this:

using (var serviceClientWrapper = new ServiceClientWrapper<ManagementServiceClient, IManagementService>(config))
{
    serviceClientWrapper.CreateServiceClient().CallService();
}

...where config is a WebServiceConfig - a simple Data Bag which contains details of the service to call:

using System.Security.Cryptography.X509Certificates;

public class WebServiceConfig
{
    public string Binding
    {
        get;
        set;
    }

    public string Endpoint
    {
        get;
        set;
    }

    public bool IgnoreSslErrors
    {
        get;
        set;
    }

    public X509Certificate2 ClientCertificate
    {
        get;
        set;
    }
}

Having worked with the client on previous projects I'd noticed some problems with it; every time you use it you have to write a using statement and call CreateServiceClient(). That's a minor inconvenience, but a bigger problem comes with unit testing code that uses it - newing up the ServiceClientWrapper makes it impossible to mock, but the class being IDisposable means it's intended for one-shot uses and isn't an appropriate candidate to be injected as a dependency. I worked around this by injecting in a ServiceClientWrapperFactory class which I could mock, but at some point I read Jimmy Bogard advise that your design may be flawed if you're making objects which do nothing but create other objects, and while I generally have no problem changing a design to make it more testable, I knew this was one of those occasions.

So I had these problems to solve:

Stop the user having to write using statements
Make the client injectable
Make the client mockable or stubbable
Get rid of the factory class which did nothing but make clients for unit tests

I'd also noticed a lot of boilerplate code to handle exceptions and retry service calls, and I wanted to get rid of that, too.

Thanks to these requirements, the class I wrote ended up being quite different to the previous client. It's still IDisposable (more on why later) but it hides the process of creating and using a service client inside two Execute() methods. The previous client being constructed with a config limited its use to the service and setup defined therein - the new client is passed a config through its Execute() methods, which means the same instance can be used to call different services with different settings.

This is the new class I wrote:

using System;
using System.Net;
using System.Net.Security;
using System.ServiceModel;

public class ServiceClientWrapper<TClient, TService> : IDisposable
    where TClient : ClientBase<TService>, TService
    where TService : class
{
    private TClient _serviceClient;

    public void Execute(
        WebServiceConfig config,
        Action<TService> serviceCall,
        Action<CommunicationException> commsExceptionHandler = null,
        int numberOfTimesToRetry = 1)
    {
        Execute<object>(
            config,
            service => { serviceCall.Invoke(service); return null; },
            commsExceptionHandler,
            numberOfTimesToRetry);
    }

    public TResult Execute<TResult>(
        WebServiceConfig config,
        Func<TService, TResult> serviceCall,
        Action<CommunicationException> commsExceptionHandler = null,
        int numberOfTimesToRetry = 1)
    {
        SetupSecurity(config);

        var i = 0;
        CommunicationException thrownException = null;

        while (i < numberOfTimesToRetry)
        {
            this.DisposeExistingServiceClientIfRequired(); 

            try
            {
                return serviceCall.Invoke(CreateServiceClient(config));
            }
            catch (CommunicationException faultEx)
            {
                thrownException = faultEx;

                if (commsExceptionHandler != null)
                {
                    try
                    {
                        commsExceptionHandler.Invoke(thrownException);
                    }
                    catch (CommunicationException rethrownEx)
                    {
                        thrownException = rethrownEx;
                    }
                }

                ++i;
            }
            finally
            {
                this.DisposeExistingServiceClientIfRequired();
            }
        }

        throw thrownException;
    }

    private static void SetupSecurity(WebServiceConfig config)
    {
        if (config.IgnoreSslErrors)
        {
            ServicePointManager.ServerCertificateValidationCallback =
                (obj, certificate, chain, errors) => true;
        }
        else
        {
            ServicePointManager.ServerCertificateValidationCallback =
                (obj, certificate, chain, errors) => errors == SslPolicyErrors.None;
        }
    }

    protected virtual TService CreateServiceClient(WebServiceConfig config)
    {
        // Or you can use:
        // this._serviceClient = (TClient)typeof(TClient).GetInstance(
        //     config.Binding,
        //     new EndpointAddress(config.Endpoint));
        this._serviceClient = (TClient)Activator.CreateInstance(
            typeof(TClient),
            config.Binding,
            new EndpointAddress(config.Endpoint));

        return _serviceClient;
    }

    public void Dispose()
    {
        this.DisposeExistingServiceClientIfRequired();
    }

    private void DisposeExistingServiceClientIfRequired()
    {
        if (this._serviceClient != null)
        {
            try
            {
                if (this._serviceClient.State == CommunicationState.Faulted)
                {
                    this._serviceClient.Abort();
                }
                else
                {
                    this._serviceClient.Close();
                }
            }
            catch
            {
                this._serviceClient.Abort();
            }

            this._serviceClient = null;
        }
    }
}

At its simplest you use it like this - note that this time it's a member of the class using it - it's been injected in through the constructor, for instance:

this._serviceClientWrapper.Execute(
    config,
    service => service.DoSomething());

If you have a service which returns a value, you can call it like this:

var response = this._serviceClientWrapper.Execute(
    config,
    service => service.GetResponse());

If you want to handle CommunicationExceptions yourself, you can pass in a handler:

var response = this._serviceClientWrapper.Execute(
    config,
    service => service.GetResponseWhichMightError(),
    commsException => SendMeAnEmailAboutThis(commsException));

...and if you want to retry a service call when CommunicationExceptions are thrown, you can pass in the number of times to retry:

var response = this._serviceClientWrapper.Execute(
    config,
    service => service.GetUnreliableResponse(),
    commsException => SendMeAnEmailAboutThis(commsException),
    numberOfTimesToRetry: 3);

And so to the testability! Moving the WCF client creation code into a dedicated virtual CreateServiceClient method makes the client wrapper stubbable:

using System.ServiceModel;

public class StubServiceClientWrapper<TClient, TService> : ServiceClientWrapper<TClient, TService>
    where TClient : ClientBase<TService>, TService
    where TService : class
{
    private readonly TService _serviceClientToReturn;

    public StubServiceClientWrapper(TService serviceClientToReturn)
    {
        this._serviceClientToReturn = serviceClientToReturn;
    }

    protected override TService CreateServiceClient(WebServiceConfig config)
    {
        return this._serviceClientToReturn;
    }
}

...where the stub is created with a TService instance to return from the overridden CreateServiceClient method. Then - as an example - a Service class like this:

public class Service
{
    private readonly WebServiceConfig _config;
    private readonly ServiceClientWrapper<ManagementServiceClient, IManagementService> _serviceClientWrapper;

    public Service(
        WebServiceConfig config,
        ServiceClientWrapper<ManagementServiceClient, IManagementService> serviceClientWrapper)
    {
        this._config = config;
        this._serviceClientWrapper = serviceClientWrapper;
    }

    public string GetResponse()
    {
        return this._serviceClientWrapper.Execute(
            this._config,
            serviceClient => serviceClient.GetResponse());
    }
}

...can be tested using a combination of the stub and a mock (using Moq in this case) like this:

var config = new WebServiceConfig
{
    Binding = "MyBinding",
    Endpoint = "http://service.com/Service.svc"
};

var wcfClient = new Mock<IManagementService>();
wcfClient.Setup(wcf => wcf.GetResponse()).Returns("Hello!");

var stubClientWrapper = new StubServiceClientWrapper<ManagementServiceClient, IManagementService>(
    wcfClient.Object);

var service = new Service(config, stubClientWrapper);

var serviceResponse = service.GetResponse();

Assert.AreEqual("Hello!", serviceResponse);

And there we have it - a unit-testable WCF service client wrapper. Because the stub only overrides the CreateServiceClient method everything else can be unit tested, including the retry and error-handling behaviour.

As mentioned, the new client wrapper is still IDisposable, even though you should never end up with an undisposed WCF client within it; I chose to leave it as IDisposable because classes with disposable members should themselves be disposable.

GetValueOrDefault() For An Expression of Arbitrary Length Using Expression Trees

Steve Wilkes — Thu, 10 Jan 2013 11:26:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2013/01/10/getvalueordefault-expression-object-graph-arbitrary-length-depth-expression-tree.aspx

In my most recent project we had to support classes with fairly deep object graphs where any of the nodes could validly be null. We didn't want to have lots of 'if not null' checks everywhere, so I wrote an extension method which takes an expression of any length and returns the expression value or a default value if any of the nodes are null. It enabled us to do this - for this example let's say we've got a Person class which has an Address property of type Address, which in turn has a Postcode property of type Postcode, which itself has a Value property of type string:

person.GetValueOrDefault(p => p.Address.Postcode.Value);

You can also optionally pass in a default value to return, like this:

person.GetValueOrDefault(p => p.Address.Postcode.Value, "No postcode");

If person, person.Address or person.Address.Postcode are null the default value is returned. Here's the code for the extension method, followed by an overview of how it works:

using System;
using System.Linq;
using System.Linq.Expressions;
using System.Collections.Concurrent;

public static class ObjectExtensions
{
    public static TResponse GetValueOrDefault<T, TResponse>(
        this T root,
        Expression<Func<T, TResponse>> property,
        TResponse defaultValue = default(TResponse))
        where T : class
    {
        if (root == null)
            return defaultValue;
 
        return ValueOrDefaultCache<T, TResponse>.Cache
            .GetOrAdd(property.Body.ToString(), key => CreateValueOrDefaultLambda(property))
            .Invoke(root, defaultValue);
    }
 
    private static Func<T, TResponse, TResponse> CreateValueOrDefaultLambda<T, TResponse>(
        Expression<Func<T, TResponse>> property)
        where T : class
    {
        var rootParameter = property.Parameters.First();
        var defaultValueParameter = Expression.Parameter(typeof(TResponse), "default");
 
        var memberExpression = (MemberExpression)property.Body;
        Expression valueOrDefaultExpression = null;
 
        while (memberExpression != null)
        {
            var memberDefaultValue = Expression.Default(memberExpression.Type);
            var memberIsNotDefault = Expression.NotEqual(memberExpression, memberDefaultValue);
 
            valueOrDefaultExpression = Expression.Condition(
                memberIsNotDefault,
                (valueOrDefaultExpression ?? memberExpression),
                defaultValueParameter);
 
            memberExpression = memberExpression.Expression as MemberExpression;
        }
 
        var lambda = Expression.Lambda<Func<T, TResponse, TResponse>>(
            valueOrDefaultExpression, 
            rootParameter,
            defaultValueParameter);
 
        return lambda.Compile();
    }
 
    private static class ValueOrDefaultCache<T, TResponse>
    {
        public static readonly ConcurrentDictionary<string, Func<T, TResponse, TResponse>> Cache =
            new ConcurrentDictionary<string, Func<T, TResponse, TResponse>>();
    }
}

The ValueOrDefaultCache class contains a ConcurrentDictionary which caches functions which return a value or default for a given expression against the 'signature' of the expression itself. Because ValueOrDefaultCache is static and generic, one dictionary and set of functions is cached per root and leaf object type, ensuring the functions are unique. To illustrate, the cache entry for our person.GetValueOrDefault() example above looks like this:

The cached method is built using Expression Trees; starting at the leaf the while loop walks back up to the expression root, creating a nested ternary condition for each node. The condition's true branch returns the expression value for the leaf node, or the set of ternary conditions so far for the other nodes. The false branch returns the default value - either that supplied by the caller or the default value of the leaf node's Type. Once a set of ternary operators has been built which checks the entire expression, a Lambda Expression is created and compiled into the function to be cached and executed.

For example, on the first pass over the loop for our person.GetValueOrDefault() example:

...the valueOrDefaultExpression goes as far as checking if p.Address.Postcode.Value is different to the default value for string; if it is it returns it, otherwise it returns the value of the default parameter passed to the function. The second time around the loop looks like this:

...now the conditional checks if p.Address.Postcode is different to the default value for Postcode; if it is it returns the result of the first conditional, otherwise as before it returns the value of the default parameter passed to the function.

The Expression continues to built in this way to an arbitrary depth. Eventually the expression from our example looks like this:

And we've got a way of checking each node in an object graph of arbitrary depth to make sure it has a value. The expression is compiled and the resulting function cached, so the next time we execute person.GetValueOrDefault(p => p.Address.Postcode.Value), it runs at almost native speed.

This version of the function only deals with MemberAccessExpressions, which means it doesn't deal with CallExpressions; calls to instance or extension methods. Maybe I'll update it to do so at some point, otherwise I'll leave it as an exercise for the reader :)

Extending WatiN 3: Detecting if a PDF Has Opened In a New Window

Steve Wilkes — Fri, 04 Jan 2013 15:28:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2013/01/04/watin-detect-if-pdf-opened-in-new-window.aspx

WatiN lets you attach to browser windows so you can verify their contents and close them as part of your tests, but the standard API doesn't detect windows with PDF documents in them. Adapted from this answer on StackOverflow, here's an extension method which does.

private static readonly ConstraintContext _emptyConstraintContext = new ConstraintContext();

public static TPage ShouldOpenANewWindow<TPage>(
    this TPage page,
    Action<TPage> windowOpeningAction,
    Constraint windowFindMethod,
    bool closeBrowserIfExists = true)
    where TPage : BasePage
{
    Assert.IsFalse(Browser.Exists<IE>(windowFindMethod));
 
    windowOpeningAction.Invoke(page);
 
    // Make sure the opening window hasn't been replaced by checking a window 
    // still exists with the Title of the Document of the given page:
    Assert.IsTrue(Browser.Exists<IE>(Find.ByTitle(page.Document.Title)));
 
    InternetExplorer matchingWindow = null;
            
    // Try 10 times to find a matching window:
    for (int i = 0; i < 10; i++)
    {
        foreach (InternetExplorer internetExplorer in new ShellWindowsClass())
        {
            if (internetExplorer.FullName.Contains("iexplore.exe"))
            {
                if (windowFindMethod.Matches(
                    new TitleAndUrlAttributeBag(internetExplorer.LocationName, internetExplorer.LocationURL),
                    _emptyConstraintContext))
                {
                    matchingWindow = internetExplorer;
                    break;
                }
            }
        }
 
        if (matchingWindow != null)
        {
            break;
        }
 
        // None of the currently-open IE windows matches the given title or URL; 
        // wait for 1 second then try again:
        Thread.Sleep(1000);
    }
 
    if (matchingWindow == null)
    {
        Assert.Fail("The expected new browser window was not found.");
    }
 
    if (closeBrowserIfExists)
    {
        matchingWindow.Quit();
    }
 
    return page;
}

The method extends a base Page class, assuming that you're using WatiN's Page pattern. You invoke it on an instance of a page, passing in an action which is expected to cause the new window to open, and a WatiN Constraint detailing how to identify the window if it exists. The Constraint is passed a TitleAndUrlAttributeBag, a simple implementation of WatiN's IAttributeBag interface which provides title and URL values only. This means you can only use Constraints which check window titles or URLs, but this should be sufficient for most cases. Here's the TitleAndUrlAttributeBag source:

internal class TitleAndUrlAttributeBag : IAttributeBag
{
    private readonly Dictionary<string, string> _attributes;

    public TitleAndUrlAttributeBag(string windowTitle, string browserUrl)
    {
        this._attributes = new Dictionary<string, string>
        {
            { "title", windowTitle },
            { "href", browserUrl}
        };
    }

    public T GetAdapter<T>() where T : class
    {
        return default(T);
    }

    public string GetAttributeValue(string attributeName)
    {
        return this._attributes[attributeName];
    }
}

Note the hard-coded strings "title" and "href"; these are the values WatiN will request when processing an AttributeConstraint for a title or URL respectively.

So, given this Page class:

internal class MyPage : BasePage
{
    public void ViewTermsAndConditions()
    {
        this.Document.Link(Find.ById("terms-and-conditions")).Click();
    }
}

...you can use the extension method to check a Terms and Conditions PDF opens in a new window like this:

var myPage = new MyPage();

myPage.ShouldOpenANewWindow(
    page => page.ViewTermsAndConditions(), 
    Find.ByUrl(url => url.EndsWith("terms.pdf")));

Extending WatiN 2: Wait for JQuery document.ready() Functions to Complete

Steve Wilkes — Thu, 29 Nov 2012 19:22:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/11/29/making-watin-wait-for-jquery-document-ready-functions-to-complete.aspx

WatiN's DomContainer.WaitForComplete() method pauses test execution until the DOM has finished loading, but if your page has functions registered with JQuery's ready() function, you'll probably want to wait for those to finish executing before testing it. Here's a WatiN extension method which pauses test execution until that happens.

JQuery (as far as I can see) doesn't provide an event or other way of being notified of when it's finished running your ready() functions, so you have to get around it another way. Luckily, because ready() executes the functions it's given in the order they're registered, you can simply register another one to add a 'marker' div to the page, and tell WatiN to wait for that div to exist. Here's the code; I added the extension method to Browser rather than DomContainer (Browser derives from DomContainer) because it's the sort of thing you only execute once for each of the pages your test loads, so Browser seemed like a good place to put it.

public static void WaitForJQueryDocumentReadyFunctionsToComplete(this Browser browser)
{
    // Don't try this if JQuery isn't defined on the page:
    if (bool.Parse(browser.Eval("typeof $ == 'function'")))
    {
        const string jqueryCompleteId = "jquery-document-ready-functions-complete";
 
        // Register a ready() function which adds a marker div to the body:
        browser.Eval(
           @"$(document).ready(function() { " + 
                "$('body').append('<div id=""" + jqueryCompleteId + @""" />'); " + 
            "});");

        // Wait for the marker div to exist or make the test fail:
        browser.Div(Find.ById(jqueryCompleteId))
               .WaitUntilExistsOrFail(10, "JQuery document ready functions did not complete.");
    }
}

The code uses the Eval() method to send JavaScript to the browser to be executed; first to check that JQuery actually exists on the page, then to add the new ready() method. WaitUntilExistsOrFail() is another WatiN extension method I've written (I've ended up writing really quite a lot of them) which waits for the element on which it is invoked to exist, and uses Assert.Fail() to fail the test with the given message if it doesn't exist within the specified number of seconds. Here it is:

public static void WaitUntilExistsOrFail(this Element element, int timeoutInSeconds, string failureMessage)
{
    try
    {
        element.WaitUntilExists(timeoutInSeconds);
    }
    catch (WatiNTimeoutException)
    {
        Assert.Fail(failureMessage);
    }
}

WatiNTimeoutException is a using alias for WatiN.Core.Exceptions.TimeoutException:

using WatiNTimeoutException = WatiN.Core.Exceptions.TimeoutException;

...I use an alias to avoid a conflict with the base class libraries' System.TimeoutException.

No More NCrunch For Me

Steve Wilkes — Sun, 28 Oct 2012 10:20:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/10/28/ncrunch-review-issues-problems-pros-cons.aspx

When I opened up Visual Studio this morning, I was greeted with this little popup:

NCrunch is a Visual Studio add-in which runs your tests while you work so you know if and when you've broken anything, as well as providing coverage indicators in the IDE and coverage metrics on demand. It recently went commercial (which I thought was fair enough), and time is running out for the free version I've been using for the last couple of months. From my experiences using NCrunch I'm going to let it expire, and go about my business without it. Here's why.

Before I start, let me say that I think NCrunch is a good product, which is to say it's had a positive impact on my programming. I've used it to help test-drive a library I'm making right from the start of the project, and especially at the beginning it was very useful to have it run all my tests whenever I made a change. The first problem is that while that was cool to start with, it’s recently become a bit of a chore.

Problems Running Tests

NCrunch has two 'engine modes' in which it can run tests for you - it can run all your tests when you make a change, or it can figure out which tests were impacted and only run those. Unfortunately, it became clear pretty early on that that second option (which is marked as 'experimental') wasn't really working for me, so I had to have it run everything. With a smallish number of tests and while I was adding new features that was great, but I've now got 445 tests (still not exactly loads) and am more in a 'clean and tidy' mode where I know that a change I'm making will probably only affect a particular subset of the tests. With that in mind it's a bit of a drag sitting there after I make a change and having to wait for NCrunch to run everything. I could disable it and manually run the tests I know are impacted, but then what's the point of having NCrunch? If the 'impacted only' engine mode worked well this problem would go away, but that's not what I found.

Secondly, what's wrong with this picture?

I've got 445 tests, and NCrunch has queued 455 tests to run. So it's queued duplicate tests - in this quickly-screenshotted case 10, but I've seen the total queue get up over 600. If I'm already itchy waiting for it to run all my tests against a change I know only affects a few, I'm even itchier waiting for it to run a lot of them twice.

Problems With Code Coverage

NCrunch marks each line of code with a dot to say if it's covered by tests - a black dot says the line isn't covered, a red dot says it's covered but at least one of the covering tests is failing, and a green dot means all the covering tests pass. It also calculates coverage statistics for you. Unfortunately, there's a couple of flaws in the coverage.

Firstly, it doesn't support ExcludeFromCodeCoverage attributes. This feature has been requested and I expect will be included in a later release, but right now it doesn't. So this:

...is counted as a non-covered line, and drags your coverage statistics down. Hmph. As well as that, coverage of certain types of code is missed. This:

...is definitely covered. I am 100% absolutely certain it is, by several tests. NCrunch doesn't pick it up, down go my coverage statistics. I've had NCrunch find genuinely uncovered code which I've been able to remove, and that's great, but what's the coverage percentage on this project? Umm... I don't know.

Conclusion

None of these are major, tool-crippling problems, and I expect NCrunch to get much better in future releases. The current version has some great features, like this:

...that's a line of code with a failing test covering it, and NCrunch can run that failing test and take me to that line exquisitely easily. That's awesome! I'd happily pay for a tool that can do that. But here's the thing: NCrunch (currently) costs $159 (about £100) for a personal licence and $289 (about £180) for a commercial one. I'm not sure which one I'd need as my project is a personal one which I'm intending to open-source, but I'm a professional, self-employed developer, but in any case - that seems like a lot of money for an imperfect tool. If it did everything it's advertised to do more or less perfectly I'd consider it, but it doesn't. So no more NCrunch for me.

Extending WatiN: Useful Extension Methods

Steve Wilkes — Fri, 26 Oct 2012 15:53:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/10/26/watin-set-text-is-element-visible-is-field-hidden-extension-methods.aspx

I've been doing a fair amount of UI testing using WatiN recently – here’s some extension methods I've found useful.

This checks if a WatiN TextField is actually a hidden field. WatiN makes no distinction between text and hidden inputs, so this can come in handy if you render an input sometimes as hidden and sometimes as a visible text field. Note that this doesn't check if an input is visible (I've got another extension method for that in a moment), it checks if it’s hidden.

public static bool IsHiddenField(this TextField textField)
{
    if (textField == null || !textField.Exists)
    {
        return false;
    }

    var textFieldType = textField.GetAttributeValue("type");

    return (textFieldType != null) && textFieldType.ToLowerInvariant() == "hidden";
}

The next method quickly sets the value of a text field to a given string. By default WatiN types the text you give it into a text field one character at a time which can be necessary if you have behaviour you want to test which is triggered by individual key presses, but which most of time is just painfully slow; this method dumps the text in in one go. Note that if it's not a hidden field then it gives it focus first; this helps trigger validation once the value has been set and focus moves elsewhere.

public static void SetText(this TextField textField, string value)
{
    if ((textField == null) || !textField.Exists)
    {
         return;
    }

    if (!textField.IsHiddenField())
    {
        textField.Focus();
    }

    textField.Value = value;
}

Finally, here's a method which checks if an Element is currently visible. It does so by walking up the DOM and checking for a Style.Display of 'none' on any element between the one on which the method is invoked, and any of its ancestors.

public static bool IsElementVisible(this Element element)
{
    if ((element == null) || !element.Exists)
    {
        return false;
    }

    while ((element != null) && element.Exists)
    {
        if (element.Style.Display.ToLowerInvariant().Contains("none"))
        {
            return false;
        }

        element = element.Parent;
    }

    return true;
}

Hope they come in handy

Unobtrusive Maximum Input Lengths with JQuery and FluentValidation

Steve Wilkes — Wed, 03 Oct 2012 16:58:34 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/10/03/unobtrusive-jquery-validation-input-maxlengths-with-fluentvalidation.aspx

If you use FluentValidation and set a maximum length for a string or a maximum value for a numeric property, JQuery validation is used to show an error message when the user inputs too many characters or a numeric value which is too big. On a recent project we wanted to use input’s maxlength attribute to prevent a user from entering too many characters rather than cure the problem with an error message, and I added this JQuery to add maxlength attributes based on JQuery validation’s data- attributes.

$(function () {
    $("input[data-val-range-max],input[data-val-length-max]").each(function (i, e) {
        var input = $(e);
        var maxlength = input.is("[data-val-range-max]")
            ? input.data("valRangeMax").toString().length
            : input.data("valLengthMax");
        input.attr("maxlength", maxlength);
    });
});

Presto!

Fixing Chrome’s AJAX Request Caching Bug

Steve Wilkes — Thu, 30 Aug 2012 17:58:00 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/08/30/fixing-chromes-ajax-post-request-caching-bug.aspx

I recently had to make a set of web pages restore their state when the user arrived on them after clicking the browser’s back button. The pages in question had various content loaded in response to user actions, which meant I had to manually get them back into a valid state after the page loaded.

I got hold of the page’s data in a JavaScript ViewModel using a JQuery ajax call, then iterated over the properties, filling in the fields as I went. I built in the ability to describe dependencies between inputs to make sure fields were filled in in the correct order and at the correct time, and that all worked nicely. To make sure the browser didn’t cache the AJAX call results I used the JQuery’s cache: false option, and ASP.NET MVC’s OutputCache attribute for good measure. That all worked perfectly… except in Chrome.

Chrome insisted on retrieving the data from its cache. cache: false adds a random query string parameter to make the browser think it’s a unique request – it made no difference. I made the AJAX call a POST – it made no difference.

Eventually what I had to do was add a random token to the URL (not the query string) and use MVC routing to deliver the request to the correct action. The project had a single Controller for all AJAX requests, so this route:

routes.MapRoute(
    name: "NonCachedAjaxActions",
    url: "AjaxCalls/{cacheDisablingToken}/{action}",
    defaults: new { controller = "AjaxCalls" },
    constraints: new { cacheDisablingToken = "[0-9]+" });

…and this amendment to the ajax call:

function loadPageData(url) {
    // Insert a timestamp before the URL's action segment:
    var indexOfFinalUrlSeparator = url.lastIndexOf("/");
    var uniqueUrl =
        url.substring(0, (indexOfFinalUrlSeparator + 1)) +
        new Date().getTime() + 
        url.substring(indexOfFinalUrlSeparator);
    // Call the now-unique action URL:
    $.ajax(uniqueUrl, { cache: false, success: completePageDataLoad });
}

…did the trick.

A Super-Fast C# Extension Method using Expression Trees to Create an instance from a Type

Steve Wilkes — Sun, 19 Feb 2012 19:42:18 GMT

Originally posted on: http://geekswithblogs.net/mrsteve/archive/2012/02/19/a-fast-c-sharp-extension-method-using-expression-trees-create-instance-from-type-again.aspx

Having written an extension method to create an instance from a Type and been a bit underwhelmed by its performance, I looked into exactly what was happening and have now got it working much, much faster.

To recap, the problem with the first version of this method is that it cached the Funcs it created with all their argument types as object, which meant they had to be cast every time the Func was invoked. This can be seen in all the Convert calls in Visual Studio's expression visualiser:

It turned out that this way of doing things was 10 times slower than using Activator.CreateInstance() with no constructor parameters, and took 70% of the time when one or more parameters was used. I was sure I could improve on that :)

With the source of the performance problem being the type of the cache forcing casting of the arguments, what I needed was a type-safe cache. The types in question are the types of the constructor parameters used when Type.GetInstance() is called, so what I needed was some sort of dynamic cache which would retain those types. I read C# in Depth recently, and picked up a handy bit of trivia to do with static, generic types.

When you use a static generic type, the C# compiler creates a singleton instance of that type for each unique combination of type parameters you use. That means with a static, generic helper class, the compiler would create a type-safe cache for me, which I can key by the Type being constructed. So that was what I did:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;
 
public static class TypeExtensions
{
    /// <summary>
    /// Returns an instance of the <paramref name="type"/> on which the method is invoked.
    /// </summary>
    /// <param name="type">The type on which the method was invoked.</param>
    /// <returns>An instance of the <paramref name="type"/>.</returns>
    public static object GetInstance(this Type type)
    {
        return GetInstance<TypeToIgnore>(type, null);
    }
 
    /// <summary>
    /// Returns an instance of the <paramref name="type"/> on which the method is invoked.
    /// </summary>
    /// <typeparam name="TArg">The type of the argument to pass to the constructor.</typeparam>
    /// <param name="type">The type on which the method was invoked.</param>
    /// <param name="argument">The argument to pass to the constructor.</param>
    /// <returns>An instance of the given <paramref name="type"/>.</returns>
    public static object GetInstance<TArg>(this Type type, TArg argument)
    {
        return GetInstance<TArg, TypeToIgnore>(type, argument, null);
    }
 
    /// <summary>
    /// Returns an instance of the <paramref name="type"/> on which the method is invoked.
    /// </summary>
    /// <typeparam name="TArg1">The type of the first argument to pass to the constructor.</typeparam>
    /// <typeparam name="TArg2">The type of the second argument to pass to the constructor.</typeparam>
    /// <param name="type">The type on which the method was invoked.</param>
    /// <param name="argument1">The first argument to pass to the constructor.</param>
    /// <param name="argument2">The second argument to pass to the constructor.</param>
    /// <returns>An instance of the given <paramref name="type"/>.</returns>
    public static object GetInstance<TArg1, TArg2>(this Type type, TArg1 argument1, TArg2 argument2)
    {
        return GetInstance<TArg1, TArg2, TypeToIgnore>(type, argument1, argument2, null);
    }
 
    /// <summary>
    /// Returns an instance of the <paramref name="type"/> on which the method is invoked.
    /// </summary>
    /// <typeparam name="TArg1">The type of the first argument to pass to the constructor.</typeparam>
    /// <typeparam name="TArg2">The type of the second argument to pass to the constructor.</typeparam>
    /// <typeparam name="TArg3">The type of the third argument to pass to the constructor.</typeparam>
    /// <param name="type">The type on which the method was invoked.</param>
    /// <param name="argument1">The first argument to pass to the constructor.</param>
    /// <param name="argument2">The second argument to pass to the constructor.</param>
    /// <param name="argument3">The third argument to pass to the constructor.</param>
    /// <returns>An instance of the given <paramref name="type"/>.</returns>
    public static object GetInstance<TArg1, TArg2, TArg3>(
        this Type type,
        TArg1 argument1,
        TArg2 argument2,
        TArg3 argument3)
    {
        return InstanceCreationFactory<TArg1, TArg2, TArg3>
            .CreateInstanceOf(type, argument1, argument2, argument3);
    }
 
    // To allow for overloads with differing numbers of arguments, we flag arguments which should be 
    // ignored by using this Type:
    private class TypeToIgnore
    {
    }
 
    private static class InstanceCreationFactory<TArg1, TArg2, TArg3>
    {
        // This dictionary will hold a cache of object-creation functions, keyed by the Type to create:
        private static readonly Dictionary<Type, Func<TArg1, TArg2, TArg3, object>> _instanceCreationMethods = 
            new Dictionary<Type, Func<TArg1, TArg2, TArg3, object>>();
 
        public static object CreateInstanceOf(Type type, TArg1 arg1, TArg2 arg2, TArg3 arg3)
        {
            CacheInstanceCreationMethodIfRequired(type);
 
            return _instanceCreationMethods[type].Invoke(arg1, arg2, arg3);
        }
 
        private static void CacheInstanceCreationMethodIfRequired(Type type)
        {
            // Bail out if we've already cached the instance creation method:
            if (_instanceCreationMethods.ContainsKey(type))
            {
                return;
            }
 
            var argumentTypes = new[] { typeof(TArg1), typeof(TArg2), typeof(TArg3) };
 
            // Get a collection of the constructor argument Types we've been given; ignore any 
            // arguments which are of the 'ignore this' Type:
            Type[] constructorArgumentTypes = argumentTypes.Where(t => t != typeof(TypeToIgnore)).ToArray();
 
            // Get the Constructor which matches the given argument Types:
            var constructor = type.GetConstructor(
                BindingFlags.Instance | BindingFlags.Public,
                null,
                CallingConventions.HasThis,
                constructorArgumentTypes,
                new ParameterModifier[0]);
 
            // Get a set of Expressions representing the parameters which will be passed to the Func:
            var lamdaParameterExpressions = new[]
            {
                Expression.Parameter(typeof(TArg1), "param1"),
                Expression.Parameter(typeof(TArg2), "param2"),
                Expression.Parameter(typeof(TArg3), "param3")
            };
 
            // Get a set of Expressions representing the parameters which will be passed to the constructor:
            var constructorParameterExpressions = lamdaParameterExpressions
                .Take(constructorArgumentTypes.Length)
                .ToArray();

            // Get an Expression representing the constructor call, passing in the constructor parameters:
            var constructorCallExpression = Expression.New(constructor, constructorParameterExpressions);
 
            // Compile the Expression into a Func which takes three arguments and returns the constructed object:
            var constructorCallingLambda = Expression
                .Lambda<Func<TArg1, TArg2, TArg3, object>>(constructorCallExpression, lamdaParameterExpressions)
                .Compile();
 
            _instanceCreationMethods[type] = constructorCallingLambda;
        }
    }
}

The Funcs created by this version of the method now look like this in the Expression Visualiser:

That's more like it - no casting! So how does it perform compared to the previous set of methods? Well, here's the output of the same performance measurement I ran before; the third column shows the total number of ticks taken to create 100,000 objects, the fourth the number of ticks taken per object:

To sum up the improvement:

An instance is now created in 5 ticks - between 10% and 7% of the time taken by Activator.CreateInstance()
Because the arguments aren't cast, performance doesn't degrade when constuctors are used with extra parameters

That's more like it! I was especially pleased to be able to apply a bit of trivia I read from a C# book to a problem like this and see a genuine improvement. The more I use and get used to Expression Trees, the more I like them and find uses for them :)