Testing Data AccessApplication Block/DAAB based objects using NUnit and VS.NET 2003 RRS feed

  • Question

  • User-1730138347 posted
    There must be a definitive solution to this - is there a way to do unit testing on classes based on Microsoft.Practices.EnterpriseLibrary Data AccessApplication Block (DAAB) using VS.NET 2003?  Once NUnit is installed, VS.NET 2003 provides two ways to test:  build a test project, right click on the project and select "Test With..." from the pop-up menu.  You'll see 2 menu items:  Debugger and NUnit GUI.  You'll be able to debug either way but if any of your test methods call the DAAB, the tests will fail at the DAAB level as configuration info is missing.

    Before we proceed, let's just stipulate that I can create and use objects that are based on the DAAB and work just fine in applications.  I'd also like to say that I already know how to create test classes and execute them with the debugger and NUnit.  Finally, I already know about VSTS 2005 and its built-in unit testing capabilities but that isn't an option here. 

    So what I want to do is to set up tests for data access layer classes that I can run in VS.NET 2003 using either the debugger or NUnit  The problems are:
    - Assemblies can't access the app.config and the dataConfiguration.config file natively.
    - NUnit.exe can't find the app.config file and so your classes/objects that use the DAAB don't get an config information (i.e. connection strings).
    - The VS.NET 2003 debugger looks for the .config files in a temporary directory.

    It is my understanding that the reason that NUnit testing does not work in this scenario because NUnit-gui.exe is looking for the config file.  I have no idea why the debugger doesn't work.  Which brings me to me questions:

    1.  How do you get unit testing in the debugger to work?  What directory is the debugger looking to find the .config files?
    2.  How do you automatically copy the .config files to the proper directories using Visual Studio 2003?
    3.  Are there any other tricks or tips to getting this to work properly?

    Thursday, November 3, 2005 9:46 AM

All replies

  • User-1730138347 posted
    Continued research indicates that there are actually 3 things going on here:
    1.  Debugging from VS.NET using NUnit.
    2.  Debugging from VS.NET using TestDriven.Net.
    3.  Locations of .config files when using the DAAB.

    I'll post more for each item.

    Friday, November 4, 2005 2:33 PM
  • User-1730138347 posted
    First, if you are using VS.NET 2003, you'll need NUnit and optionally, Test Driven .NET to do your testing.  If you need post-build events, you can either add them manually (see below) to your .vbproj files (but be careful, the IDE does not support the attributes so you can only edit the project file by hand - making changes or saving in the IDE will remove them).  There is also an add-in the you can download here

    1.  Debugging from VS.NET using NUnit.

    According to a post on
    Scott Densmore's blog everything is groovy when the config files are copied tothe NUnit bin directory as part of a post-build event.

    There is more information on how NUnit handles multiple assemblies using test projects in the PDF file that you can download from this page.

    2.  Debugging from VS.NET using TestDriven.Net.

    I found that if you copy the DAAB config files along with a renamed version of the app.config reanmed to match the name of the test assembly, TD.NET finds what it needs.  As an alternative to having a series to XCOPY or COPY statements as separate events, I create a batch file with my COPY statements and call that.   This gets around the problem of not being able to edit the events from the add-in.  I placed the following COPY commands in a file named copyconfigs.cmd:

    COPY /y d*.config .\bin
    COPY /y app.config .\bin\<Test Project Assembly Name>.dll.config

    3.  Locations of .config files when using the DAAB.

    As an alternative to copying the DAAB config files to the bin directory, I've had some success modifiying the app.config to look for the dataConfiguration.config file via relative paths.  For example, you can modify the path attribute of the <storageProvider> node to look like this:
         <storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="..\dataConfiguration.config" />

    nstead of this:

          <storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="dataConfiguration.config" />

    Cautionary note:  you will have to change this when you deploy unless you plan on maintaining a similar directory structure.

    Manually adding PostBuildEvents

    Perhaps the easiest way to to this is to create a C# project and add events thru the IDE and then open up the .csproj file in a text editor and copy the XML to your VB.NET project.  Maintaining a C# project for this purpose may also help you if you accidently modify the .vbproj file in the IDE.  Here is an example of what you should be looking to add when modify the VB.NET project (in bold for your convenience):
                    ApplicationIcon = ""
                    AssemblyKeyContainerName = ""
                    AssemblyName = "PostBuildActions"
                    AssemblyOriginatorKeyFile = ""
                    AssemblyOriginatorKeyMode = "None"
                    DefaultClientScript = "JScript"
                    DefaultHTMLPageLayout = "Grid"
                    DefaultTargetSchema = "IE50"
                    DelaySign = "false"
                    OutputType = "Library"
                    OptionCompare = "Binary"
                    OptionExplicit = "On"
                    OptionStrict = "Off"
                    RootNamespace = "PostBuildActions"
                    PostBuildEvent = 'xcopy /c/i/r/y  "$(ProjectDir)dataConfiguration.config"  "$(ProjectDir)$(OutDir)."'
                    StartupObject = ""

    In this example, we are copying the dataConfiguration.config to the output directory for the project.

    That's all I know - I hope this helps somebody else at some point.
    Tuesday, November 8, 2005 1:20 PM