Friday, April 21, 2006 8:37 PM
I am just starting out using VSTS Unit Test capabilities. I have used NUnit in the past. I have created the Test project and added an App.config file. In this file I have created a <connectionStrings> section along with an <add name="DBAMS" ... /> entry. In fact, I copied from the app.config file I was using in NUnit where it worked.
When I debug the test it is failing on the following line:
providerName = ConfigurationManager.ConnectionString["DBAMS"].ProviderName;
Turns out, it cannot find the DBAMS entry. What am I missing to get this app.config file to work correctly with my unit test?
I have several connectionString entries but ConfigurationManger.ConnectionStrings shows a count = 1 and it is for localsqlserver. I know the config file is written correctly because it works elsewhere. I also know that this particular line of code is correct as it works when I do a normal (non-test) debug. But since it hangs on this line all of my tests that involve the database are failing.
Saturday, April 22, 2006 7:02 AM
We don't pick up the app config file for the 'test execution directory' automatically.
Consider adding a [DeploymentItem("MyAppConfig.config")] attribute to the test, or edit the deployment items section of the run configuration.
It may seem unpleasant that we execute tests in a different directory than where the build output is, but this ensures that if you ever take advantage of our ability to execute tests on remote machines, all the necessary files will get copied over.
Also, it may be necessary to name the config file after your test dll. For instance, if the test dll is MyUnitTests.dll, the config deployment item should be MyUnitTests.dll.config.
Let me know if you still have trouble.
Monday, April 24, 2006 9:04 PM
We do support App.Config's being automatically picked up when you run tests. There are a number of scenarios:
From the IDE:
* Test Projects w/ App.config in the root of the project (File will be copied as AssemblyName.dll.config)
* App.Config set to copy to output directory
* AssemblyName.dll.config set to copy to the output directory
From the commandline (mstest.exe):
* App.config located next to the Test DLL
* AssemblyName.dll.config located next to test DLL
* not using /noisolation with mstest.exe
When the above are true, when ever you run a test we will pick up and apply that Configuration to the app domain. Everythign should just work fine after that -- I have tried to repro your scenario, with the following app.config:
<?xml version="1.0" encoding="utf-8" ?>
<add name="Test" connectionString="aConnectionString" providerName="aProvider"/>
and the following code in a unit test:
If you can't resolve the problem with this info could you check the following:
* The config file is making it to bin/debug on the Test Project
* When you run it, the deployment directory has the file in (This isnt so easy to find -- it's in <Solution Dir>\TestResults\user@machine DATE TIME\Out\)
Monday, March 03, 2008 3:42 AM
I just hope I am doing something equivalent to PBCAK[DeploymentItem("Db.dll.config"]
I have a project is called Db, its a dll. I added an App.config to the dll.
I did not see the Db.config in either the bin folder
I tried to put
Even that does not deploy the config file.
I tried to do the same with an EXE project, thinking the App.config is ignored if this is a DLL project, but the same issue.
The solution with 2 tests inside Test1 and the dll and exe are in :
Any help is deeply appreaciated,
thanks in advance,
Tuesday, October 06, 2009 5:08 PM
I struggled with the same area of problems for a while: how to get configuration information from your actual project into the unit testing project without duplicating? However, I found the following to be working for me:
1. Isolate your custom configuration sections into external files, then reference these external files from your web.config or app.config. This is always a good practice if you have a web project and a class project in the same solution, that should use the same config information.
One of my external files is named 'thor.security.config' and looks like this
<persistenceManager name="PersistenceManager" type="Thor.RelationalDatabase.PersistenceManager, Thor.RelationalDatabase, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null"/>
And I reference it from my web.config or app.config like this:
<section name="thor.security" type="Thor.Module.Configuration.ModuleConfiguration, Thor.Module, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null"/>
<thor.security configSource="thor.security.config" />
The obvious benefit is that any change in 'thor.security.config' is automatically picked up in the web.config and app.config without having to duplicate information.
2. Create a unit test project and link the external config file: right-click the unit testing project, select Add | Existing Item, browse to the external config file, and make sure you add it as a link (click the little arrow next to the Add button, and select Add As Link).
3. Right-click the (link to the) external config file and make sure to set Properties | Copy to Output Directory | Copy always. This will ensure that the external config file will be copied over to the bin directory of the unit testing project. Make sure that the app.config file (in which you have a reference to the external config file) in your unit testing project is also set to be copied always to the output directory.
4. However, at this stage we are only half way, since it turns out that the unit testing project is executed (logically) in a separate AppDomain and (physically) from a different directy than the usual output directory (which is the bin directory). The unit testing project executes from a directory somewhere under the 'TestResults' directory (browse to the physical directory that contains your unit testing project, and you should see this 'TestResults' directory). It turns out that running the unit tests automatically creates the execution directory under 'TestResults' and copies over the app.config file (automatically renamed to <unit test project name>.dll.config). However, the external config file is NOT copied over, so we get errors all over the place when trying to use config information in our test methods.
5. Which brings us to the last question: how to make sure that the external config file is copied over as well? In fact, this is rather simple to do, just add the DeploymentItem-attribute on top of your unit testing class like this:
public class MyUnitTests
public void MyBigTest()
//Access configuration information
//and do something with it ...
This attribute causes the runtime to pick up the concerned resource from the bin directory and get it to the actual execution directory under 'TestResults'.
- first create an app.config in your unit testing project, and reference the external config file from it
- then link the external config file into the unit testing project (as described above)
- then, in the properties, make sure that this file is copied always to the output directory
- and finally, use the Deployment attribute in the unit test class, to get the file from the output directory to the execution directory
Hope this helps,
Peter De Jonghe
Wednesday, March 07, 2012 8:12 PM
I've abided by all the above advice in my VSTS test and I get the following error:Unit Test Adapter threw exception:
The type initializer for 'Microsoft.VisualStudio.TestTools.Diagnostics.EqtTrace' threw an exception.Unable to open configSource file 'TestAppSettings.config'. (C:\Users\drvora\AppData\Local\Temp\5\tmp1C20.tmp line 11).
we have tried the following items (separately and in combination) in order to get this to work:
1) using [DeploymentItem] attribute in our test class
2) using deployment items in testsettings
3) using Load context from Unit test tab of testsettings
4) specifying to run as 64 bit process on 64 bit machine (testsettings)
5) with and without the default host specified (testsettings)
6) verifying that the included configSource is well-formed with entlib config tool
The test runs fine without the external configSource elements.
Is there anything we are not doing? Is this a known defect?