- | rssFeed | My book on MSBuild and Team Build | Archives and Categories Wednesday, December 09, 2009

Unit testing and ASP.NET MVC Comments

Unit testing has been around for quite a while and a lot of developers have created their own unit tests. Even being a simple concept and having been around for some time I still think that unit tests are misunderstood, poorly written and don't follow best practices by a majority of developers. I'm not a unit testing expert but there are some guidelines that I try to follow when I create unit tests some of those are listed below (in no particular order).

If you make your unit tests too long and to test more than one item then they will become a pain to maintain, which leads to them being ignored and eventually to a complete breakdown to your testing effort in general.

I have recently been thinking more about how unit tests are being used throughout software development. Also I've been reading ASP.NET MVC in Action which coincidently puts a lot of emphasis on unit testing. I found a few quotes in Chapter 3 of that book, which covers Controllers, and thought that I would share them here because I agree with statements whole heartedly. Text in italics are my own comments.

Some of the key take aways: use mocks, and testing should be helpful to your development process not a hindrance.

Don't write unit tests just to write them or just to get the necessary coverage. Make sure that you write the test cases with a specific intent and that they are written well so that you will continue to maintain and execute them as a part of your CI build process.

Here are some unit tests that I've recently written that I'd like to use to show some concrete cases.

[Test]

public void TestGetConfigValue_ValueExistsRequiredTrue()

{

    string key = "83F216CD-1B3E-4fc1-9DA5-4A7D506AF7E8";

    string expectedValue = "C2D4E7CA-BE6B-4976-BFA9-50F5223C603A";

    ConfigurationManager.AppSettings[key] = expectedValue;

 

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, true);

    Assert.AreEqual(expectedValue, actualValue);

}

 

[Test]

public void TestGetConfigValue_ValueExistsRequiredFalse()

{

    string key = "0601AB1F-C78C-4c72-8648-B140D50BDDEC";

    string expectedValue = "92DCADBC-9618-49f3-A412-5C90A945903D";

    ConfigurationManager.AppSettings[key] = expectedValue;

 

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, false);

    Assert.AreEqual(expectedValue, actualValue);

}

 

[Test]

public void TestGetConfigValue_ValueDoesntExistRequiredFalse()

{

    string key = "2D4B5C66-BA37-4ab8-9B51-3F17CF348E6D";

 

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, false);

    Assert.IsNull(actualValue);

}

 

[ExpectedException(typeof(ConfigurationErrorsException))]

[Test]

public void TestGetConfigValue_ValueDoesntExistRequiredTrue()

{

    string key = "0511216E-3AA6-4b80-B215-E980A459466D";

 

    // ConfigurationErrorsException here

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(key, true);

}

 

[ExpectedException(typeof(ArgumentNullException))]

[Test]

public void TestGetConfigValue_KeyIsNull_RequiredFalse()

{

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(null, false);

}

 

[ExpectedException(typeof(ArgumentNullException))]

[Test]

public void TestGetConfigValue_KeyIsNull_RequiredTrue()

{

    string actualValue = ServiceConfigHelper.Instance.GetConfigValue(null, true);

}

 

// Setup method here

[SetUp]

public void Reset()

{

    ServiceConfigHelper.Instance.Reset();

    if (ConfigurationManager.AppSettings.HasKeys())

    {

        List<string> allKeys = new List<string>();

        foreach (string key in ConfigurationManager.AppSettings.Keys)

        {

            allKeys.Add(key);

        }

 

        foreach (string key in allKeys)

        {

            ConfigurationManager.AppSettings[key] = string.Empty;

        }

    }

}

Notice that each of these has a very descriptive name, if you saw the name of the test in the list of failed test cases you immediately know what to work on; you don't even have to look at the test. Notice that all of the tests are pretty small, and that each test case tests a very specific piece of functionality. Also you might have noticed that I use Guids in test cases I like to do this just to make sure that I have random data and that test cases don't conflict with each other.

Also I'd like to note that in the book the guys recommend reading Working Effectively with Legacy Code for good coverage of unit testing, I haven't read it but I might grab a copy.

 

Sayed Ibrahim Hashimi

ASP.NET MVC | unit testing Wednesday, December 09, 2009 6:37:17 AM (GMT Standard Time, UTC+00:00)  #     | 
Monday, December 07, 2009

MSDeploy Syncing 2 or More Folders

A while back someone asked me if you could sync 2 or more folders with one statement using MSDeploy. I said of course, if you perform the sync using manifest files. Manifest files allow you to "group" sync operations into a file. When you invoke msdeploy.exe and point it to a manifest file, each provider will be executed in the order in which it appears inside the manifest file. A common scenario for using manifest files is to sync websites. This way you can specify the files that should be synced, the website (application) name, ACL values, etc. But you are not limited to using manifest files for web related sync operations. When using manifest files, you would specify the provider to be manifest. We will see this in the command used to snyc two folders. Often times when using a manifest file for the source you will also use one for the destination. Here are the two files.

SourceManifest.xml

<sitemanifest>

  <contentPath path="C:\temp\MSDeploy\Source01"/>

  <contentPath path="C:\temp\MSDeploy\Source02" />

</sitemanifest>

DestManifest.xml

<sitemanifest>

  <contentPath path="E:\temp\MSDeploy\Source01" />

  <contentPath path="E:\temp\MSDeploy\Source02" />

</sitemanifest>

In this example I am syncing two folders C:\temp\MSDeploy\Source01 and C:\temp\MSDeploy\Source02 to another drive location on E. The command to perform the sync would be

msdeploy -verb:sync -source:manifest=sourceManifest.xml -dest:manifest=destManifest.xml

And here are the results of that sync operation, when the destination directories don't exist.

C:\temp\MSDeploy>msdeploy -verb:sync -source:manifest=sourceManifest.xml -dest:manifest=destManifest.xml

Info: Adding sitemanifest (sitemanifest).

Info: Adding contentPath (E:\temp\MSDeploy\Source01).

Info: Adding dirPath (E:\temp\MSDeploy\Source01).

Info: Adding child filePath (E:\temp\MSDeploy\Source01\01.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source01\02.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source01\03.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source01\04.txt).

Info: Adding contentPath (E:\temp\MSDeploy\Source02).

Info: Adding dirPath (E:\temp\MSDeploy\Source02).

Info: Adding child filePath (E:\temp\MSDeploy\Source02\01.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source02\02.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source02\03.txt).

Info: Adding child filePath (E:\temp\MSDeploy\Source02\04.txt).

Total changes: 13 (13 added, 0 deleted, 0 updated, 0 parameters changed, 0 bytes copied)

As you can see the destination directories were created and the files synced into the destination folders. First all the content of the Source01 folder is synced and then the Source02 folder as expected. If you perform the sync operation and all files are up-to-date then no changes will be made.

This is just a very basic example of how you can use MSDeploy manifest files to perform a sync operation, but you can create manifest files that perform many different actions. Visual Studio 2010 uses manifest files when it creates the web packages for deployment.

 

Sayed Ibrahim Hashimi

MSDeploy Monday, December 07, 2009 4:50:37 AM (GMT Standard Time, UTC+00:00)  #     |