When i run a simple test on connection to DB check i receive an error in NUnit:
[Test]
public void TestConn()
{
string connectionString = Configuration
NB: if does not work try to add path to it, e.g. bin\Debug\ yourAssemblyName.dll.config
Your test project file yourAssemblyName.nunit will be updated.
And yes, be sure App.config in your test project match to what you access in test, i.e.
[Test]
public void TestConn()
{
var sss = ConfigurationManager.AppSettings["TestKey"];
}
App.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="TestKey" value="testKeyValue"/>
</appSettings>
</configuration>
I would like to add a point. There is a note in documentation of nunit, and depending upon usage scenario config file naming and placement should be done. I was stuck on this issue for a while.
Documentation says :
If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the dll.
If an NUnit project is being loaded, the configuration file uses the name of the project file with the extension changed to config. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.
http://www.nunit.org/index.php?p=configFiles&r=2.2.10
Why do you need a unit test to see if SqlConnection works? You should test your code, not Microsoft's. I don't really see the point in checking if the connection string is correct either in your unit tests. The configuration used by the unit tests isn't the same as what will be used by your production code.
In general, though, if you need some configuration data for unit tests, create an app.config file in the test project. Populate the appSettings and connectionStrings elements, etc. with appropriate values for your test environment. Don't bother testing whether ConfigurationManager or SqlConnection works, though. You'll just be creating code that you have to maintain, but that doesn't actually verify any of the production code you are writing.