Month: December 2008

Switching from MS Test to NUnit Testing

So yesterday I decided to switch my test project to use NUnit as it just feels better with using TestDriven.Net and just feels like kludgey in general. I was pleasantly surprised to see that the level of integration between NHibernate and NUnit that any of the queries that NHibernate runs will be output in the GUI for NUnit that will be really useful until it is superseded by Ayende Rahien’s NProf is released.

Among my transition to MS Test I encountered a few issues, the first of which was not being able to get any of my tests to run. No matter which test or group of tests I attempted to run I would receive this error message:

TestCase ‘Repository.Test.RepositoryTest.EmployeeDataProviderTest.CanResolveProvider’
not executed: Invalid TestFixtureSetUp method signature

Which is what I would get in my output window from running the test through TD.NET eventually I was able to trace this back to MS Test declaring it’s TestFixtureSetUp method’s (the ClassInitialize for their attribute) as static. So remember to remove the static keyword from your methods as you convert your property names to NUnit.

The other issue I ran into was I used the MS Test specific [DeploymentItem] attribute to move config files from my config directories into my test bin folders. Since that was no longer an option I went around creating my own file copy helper. The code usage feels a little less clean compared to DeploymentItem but I feel it’s acceptable on it’s own. Feel free offer any input if you think there’s any cleaner way to do this.

public static class DeploymentItem
{
    /// <summary>
    /// Deploys the files from the deployment directory to the target directory        
    /// using the specified file filter after emptying the target directory.
    /// </summary>
    /// <param name="deploymentDir">The deployment dir.</param>
    /// <param name="targetDir">The target dir.</param>
    /// <param name="fileFilter">The file filter.</param>
    public static void DeployFiles(string deploymentDir, string targetDir, string fileFilter)
    {
        if (Directory.Exists(targetDir))
            Directory.Delete(targetDir, true);

        Directory.CreateDirectory(targetDir);

        foreach (string file in Directory.GetFiles(deploymentDir, fileFilter))
        {
            string newFile = Path.Combine(targetDir, Path.GetFileName(file));

            File.Copy(file, newFile);
            File.SetAttributes(newFile, FileAttributes.Normal);
        }
    }

    /// <summary>
    /// Deploys the config deployment directory to the target directory        
    /// after emptying the target directory.
    /// </summary>
    /// <param name="configDir">The config dir.</param>
    /// <param name="targetDir">The target dir.</param>
    public static void DeployConfigs(string configDir, string targetDir)
    {
        DeployFiles(configDir, targetDir, "*.config");
    }
}

And inside my test class this is what my TestFixtureSetup method looks like

[TestFixtureSetUp]
public void TestFixtureSetup()
{
    const string relativeDir = @"..\..\..\..\..\Deploy\Development\";
    string configDir = Path.Combine(Environment.CurrentDirectory, relativeDir);
    string testConfigDir = Path.Combine(Environment.CurrentDirectory, @"Config\");
    DeploymentItem.DeployConfigs(configDir, testConfigDir);
}

I’m not fan of how many times I need to backdir my relative location based off Enviroment.CurrentDirectory at runtime this is the part I dislike most. I’d much rather be able to just figure out where the solution root is at but I couldn’t seem to find anything online that showed a way to do it so if anyone knows a better way than CurrentDirectory + “../../../../etcetcetc” please comment.

BloggingContext.ApplicationInstance.CompleteRequest();

UnityWeb back to the North

I’ve decided using the adventureworks database is more of  a hindrance than anything to UnityWeb, I will be switching back to using the Northwind database. I wanted to use the ADW DB in hopes to tackle some more complex situations since databases rarely seem to be optimal to a developer but the numerous schemas and weird cohesion levels in the ADW DB has just turned me off entirely to it. While I’m not a DBA, but this database is just appalling to me and is just a perfect example of why I hate databases in general, they are completely archaic and need to go the way of the dinosaur.

BloggingContext.ApplicationInstance.CompleteRequest();

UnityWeb Status Update

I’ve been continuing on making progress on my UnityWeb solution. I ended up backtracking for a while as I switched from the Northwind database to the Adventureworks database. I have ran my current solution on both the Adventureworks 2005 and 2008 sample so either of them should work.

I was doing my earnest to avoid having to make any changes to the database but I’ve ran into a slight stumbling block for using Fluent Nhibernates auto persistence model that it’s hard to deal with multiple tables in different schemas so I broke down and added some synonyms to the database to handle this.

For anyone that downloads my code from here on out make sure you run these synonym create statements.
USE AdventureWorks

CREATE SYNONYM [dbo].[synEmployee] FOR [AdventureWorks].[HumanResources].[vEmployee]
CREATE SYNONYM [dbo].[synJobCandidate] FOR [AdventureWorks].[HumanResources].[vJobCandidate]
CREATE SYNONYM [dbo].[synVendor] FOR [AdventureWorks].[Purchasing].[vVendor]
CREATE SYNONYM [dbo].[synCustomer] FOR [AdventureWorks].[Sales].[vIndividualCustomer]
CREATE SYNONYM [dbo].[synSalesPerson] FOR [AdventureWorks].[Sales].[vSalesPerson]
CREATE SYNONYM [dbo].[synOrders] FOR [AdventureWorks].[Sales].[SalesOrderHeader]

BloggingContext.ApplicationInstance.CompleteRequest();