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?
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.
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:
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:
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):
<Settings
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.
None
0 Points
8 Posts
Testing Data AccessApplication Block/DAAB based objects using NUnit and VS.NET 2003
Nov 03, 2005 09:46 AM|crickard|LINK
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?
++C++
None
0 Points
8 Posts
Re: Testing Data AccessApplication Block/DAAB based objects using NUnit and VS.NET 2003
Nov 04, 2005 02:33 PM|crickard|LINK
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.
None
0 Points
8 Posts
Re: Testing Data AccessApplication Block/DAAB based objects using NUnit and VS.NET 2003
Nov 08, 2005 01:20 PM|crickard|LINK
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" />
instead 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):
<Settings
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.