Ya sea que esté usando Team System Test o NUnit , la mejor práctica es crear una Biblioteca de clases separada para sus pruebas. Simplemente agregando un App.config a su proyecto de prueba se copiará automáticamente a su carpeta bin cuando compile .
Si su código depende de pruebas de configuración específicas, la primera prueba que escribiría valida que el archivo de configuración está disponible ( para que sepa que no estoy loco ):
<configuration>
<appSettings>
<add key="TestValue" value="true" />
</appSettings>
</configuration>
Y la prueba:
[TestFixture]
public class GeneralFixture
{
[Test]
public void VerifyAppDomainHasConfigurationSettings()
{
string value = ConfigurationManager.AppSettings["TestValue"];
Assert.IsFalse(String.IsNullOrEmpty(value), "No App.Config found.");
}
}
Idealmente, debería escribir código de manera que sus objetos de configuración pasen a sus clases. Esto no solo lo separa del problema del archivo de configuración, sino que también le permite escribir pruebas para diferentes escenarios de configuración.
public class MyObject
{
public void Configure(MyConfigurationObject config)
{
_enabled = config.Enabled;
}
public string Foo()
{
if (_enabled)
{
return "foo!";
}
return String.Empty;
}
private bool _enabled;
}
[TestFixture]
public class MyObjectTestFixture
{
[Test]
public void CanInitializeWithProperConfig()
{
MyConfigurationObject config = new MyConfigurationObject();
config.Enabled = true;
MyObject myObj = new MyObject();
myObj.Configure(config);
Assert.AreEqual("foo!", myObj.Foo());
}
}
