Posts Tagged ‘Testing’

Isolating Your Configuration Files For Testability

Tuesday, July 27th, 2010

 

Ben Hall over at CodeBetter just posted a nice article on using the Castle Dictionary Adapter to isolate your code from the ConfigurationManager class to make your unit tests easier to write.

I thought I might take the opportunity to talk about a technique that we use to isolate our code from ConfigurationManager and also other system classes such as the system DateTime, using the language constructs built within the .Net Framework version 3.5 and above. I’m not saying that this technique is better than the Castle Dictionary Adapter method but it just highlights an alternative approach that is possible without using third party assemblies.

Ok so using Ben’s example, because I’m too lazy to think up my own, we have an application configuration value for our EnableNewsLetterSignup.

<add key="EnableNewsletterSignup" value="false"/>

In our code we pull out the value using the static method on the ConfigurationManager class like so.

public bool Signup(string email)

{

    if (!Boolean.Parse(ConfigurationManager.AppSettings["EnableNewsletterSignup"]))

        return false;

 

    return true; // technically this would go off to an external web service

} 

Ok so nothing new here but when it comes to testing this code it means that we have to have a configuration file for our unit test project (which is bad) and we can only ever test one path through the code without changing the value of the configuration file. Which means we some untestable code without doing some configuration Kung Fu on our config file which is more work than we should have to do.

Wrapping It Up

The technique we use is to wrap our class up in a static wrapper class which we will call Config. For our corresponding application setting we add a public static field of the same name for clarity, of type Func<string>. Now the important thing is we give it it’s default behaviour which in this case is to go off and use our old friend ConfigurationManager to determine whether or not our newsletter is enabled or not.

public static class Config

{

    public static Func<string> EnableNewsletterSignup = () => ConfigurationManager.AppSettings["EnableNewsletterSignup"];

}

 

Writing Our Code

Now going back to our code where we use the application setting it will now look something like this.

public bool Signup(string email)

{

    if (!Boolean.Parse(Config.EnableNewsletterSignup()))

        return false;

 

    return true; // technically this would go off to an external web service

} 

 

Testing Our Code

So now when we want to unit test this piece of code we simply change the default behaviour of our Config class to the behaviour we want to test. See line 5 below, where we force it to return false for the purpose of our unit test. We now have total control over what our supposedly configuration value is without ever having to touch the file system.

   1: [Test]

   2: public void If_our_newsletterSignup_is_not_enabled_we_should_not_be_signed_up()

   3: {

   4:     // Arrange

   5:     Congig.EnableNewsletterSignup = () => "false";

   6:  

   7:     // Act

   8:     var isSignedUp = _classUnderTest.Signup("emailaddress@foo.com");

   9:  

  10:     // Assert

  11:     Assert.IsFalse(isSignedUp);

  12: }

 

Other Uses

As I said earlier this technique can also be quite useful for isolating other system dependant classes such as code that uses the DateTime.Now property. Sometimes if you want to logic concerning dates and times it can be pretty hard to control the flow of the code because the DateTime is generated by the system. How for example do you test something if you need to be some date in the future or some date in the past. The code below can be used in the same way to isolate our tests from the underlying call to the DateTime.Now which can be overriden as required to give the behaviour we want.

public static class SystemDateTime

{

   public static Func<DateTime> Now = () => DateTime.Now;

}

Conclusion

This approach offers an alternative solution to using the Castle Dictionary Adapter,  and although it requires writing slightly more code it does mean that it is one less assembly that you have to reference in your project which can be a good thing sometimes.

Command Line Script for Calling REST Based Web Services

Tuesday, July 13th, 2010

I have been working with REST based web services recently and whilst reading the very useful and interesting article A Guide to Designing and Building RESTful Web Services with WCF 3.5 hosted on the Microsoft web site. Came across this useful little JavaScript script that can be called from the command line to invoke your  RESTful web services.

The code is shown below.

if (WScript.Arguments.length < 2)

{

   WScript.echo("Client HTTP Request Utility\n");

   WScript.echo("usage: httprequest method uri [options]");

   WScript.echo("  -f filename");

   WScript.echo("  -h headerName headerValue");

   WScript.Quit(1);

}

var method = WScript.Arguments.Item(0);

var uri = WScript.Arguments.Item(1);

var req = new ActiveXObject("MSXML2.XMLHTTP");

var filename = null;

req.Open(method, uri, false);


WScript.echo("********* Request ********* ");

WScript.echo(method + " " + uri + " HTTP/1.1");

for (i=2; i < WScript.Arguments.length; i++)

{

    var option = WScript.Arguments.Item(i);

    if (option == "-f")

        filename = WScript.Arguments.Item(i+1);

    if (option == "-h")

    {

        WScript.echo(WScript.Arguments.Item(i+1) + ": " +

            WScript.Arguments.Item(i+2));

        req.setRequestHeader(WScript.Arguments.Item(i+1),

            WScript.Arguments.Item(i+2));

    }

}

try

{

       if (filename != null)

       {


          var fso = new ActiveXObject("Scripting.FileSystemObject");

          var file = fso.OpenTextFile(filename, 1, false);

          var fileContents = file.ReadAll();

          file.Close();

          WScript.echo(fileContents);

          req.Send(fileContents);

          printResponse(req);

       }

       else

       {

          req.send();

          printResponse(req);

       }

}

catch(e)

{


   WScript.echo("******* Response ********* ");

   WScript.echo(e.message);

}

function printResponse(req)

{


   WScript.echo("******* Response ********* ");

   WScript.echo("HTTP/1.1" + " " + req.status + " " + req.statusText);

   var headers = req.getAllResponseHeaders();

   WScript.echo(headers);

   WScript.echo(req.responseText);

}

To perform a GET simply type from the command line:

HttpUtility.js get http://localhost:1189/Service.svc/

where HttpUtility.js is the file name containing the JavaScript code shown above and the URL of our REST service.

To perform a POST:

HttpUtility.js post http://localhost:1189/Service.svc/ –f message.xml -h Content-Type application/xml

where the –f argument specifies the filename with the message contents and the –h argument indicates the header name and header value.

The source code can be downloaded from here.

Mocking HtmlHelpers in ASP.Net MVC

Friday, December 4th, 2009

NB: This post relates to version 1 of ASP.Net MVC

I recently added a static extension method for generating a custom drop down list and wanted to test it using Rhino Mocks (version 3.5).
One issue I kept banging my head against was how to create a Mock HtmlHelper in order to call the method correctly.
A number of posts later, and various attempts at using some of the sample code and I finally came across this post detailing a bunch of MVC tests.

After a minor amount of customising, I ended up with the following, which works like a charm for me to use in my tests.

        ///
        /// Creates a HTML helper for use in tests.
        ///
        private HtmlHelper CreateHtmlHelper()
        {
            var userControl = new ViewUserControl();
            var container = new ViewPage();
            container.Controls.Add(userControl);
            var context = MockRepository.GenerateMock<ViewContext>();
            userControl.ViewContext = context;

            return userControl.Html;
        }