Я тестую додаток .NET (.exe), який використовує файл app.config для завантаження властивостей конфігурації. У самій програмі тестової програми немає файлу app.config.

Коли я намагаюся випробувати тест методу, який використовує будь-яке з властивостей конфігурації, вони повертаються до нуля . Я припускаю, що це тому, що тестова програма не збирається завантажуватись у додаток цільової програми app.config.

Чи є спосіб змінити це чи потрібно написати сценарій, щоб скопіювати вміст цільової app.config в локальний app.config?

Цей пост начебто задає це питання, але автор справді дивиться на це з іншого кута, ніж я.

EDIT: Я повинен зазначити, що я використовую командну систему VS08 для моїх тестових одиниць.

Найпростіший спосіб зробити це - додати .configфайл у розділ розгортання на вашому тестовому пристрої.

Для цього відкрийте .testrunconfigфайл із пунктів Рішення. У розділ Розгортання додайте вихідні .configфайли з каталогу збирання проекту (імовірно bin\Debug).

Все, що перераховано у розділі розгортання, перед запуском тестів буде скопійовано у робочу папку тестового проекту, тож ваш конфігураційний код буде працювати нормально.

Редагувати: я забув додати, це працюватиме не у всіх ситуаціях, тому вам може знадобитися включити сценарій запуску, який перейменовує вихід, .configщоб відповідати назві тесту одиниці.

У Visual Studio 2008 я додав app.configфайл до тестового проекту як існуючий елемент і вибрав копію як посилання, щоб переконатися, що він не дублюється. Таким чином, у моєму рішенні є лише одна копія. З кількома тестовими проектами це дуже зручно!

Незалежно від того, використовуєте ви тест команди Team або NUnit , найкраща практика - створити окрему бібліотеку класів для своїх тестів. Просто додавши App.config до свого тестового проекту, автоматично під час компіляції буде скопійовано у вашу папку .

Якщо ваш код покладається на конкретні тести на конфігурацію, я б на першому тесті написав би перевірку наявності файлу конфігурації ( щоб я знав, що я не божевільний ):

<configuration>
   <appSettings>
       <add key="TestValue" value="true" />
   </appSettings>
</configuration>

І тест:

[TestFixture]
public class GeneralFixture
{
     [Test]
     public void VerifyAppDomainHasConfigurationSettings()
     {
          string value = ConfigurationManager.AppSettings["TestValue"];
          Assert.IsFalse(String.IsNullOrEmpty(value), "No App.Config found.");
     }
}

В ідеалі вам слід написати такий код, щоб об'єкти конфігурації передавались у ваші класи. Це не тільки відокремлює вас від проблеми файлу конфігурації, але також дозволяє писати тести для різних сценаріїв конфігурації.

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());
     }
}

Якщо у вас є рішення, яке містить, наприклад, веб-додаток та тестовий проект, ви, ймовірно, хочете, щоб тестовий проект використовував web.config веб-програми.

Один із способів вирішити це - скопіювати web.config для тестування проекту та перейменувати його як app.config.

Іншим і кращим рішенням є модифікація ланцюга складання і зробити її автоматичною копією web.config для тестування каталогу виводу проектів. Для цього клацніть правою кнопкою миші Тест програми та виберіть властивості. Тепер вам слід побачити властивості проекту. Натисніть кнопку "Побудувати події", а потім натисніть кнопку "Редагувати пост-збірку ...". Напишіть туди наступний рядок:

copy "$(SolutionDir)\WebApplication1\web.config" "$(ProjectDir)$(OutDir)$(TargetFileName).config"

І натисніть кнопку ОК. (Зверніть увагу, що вам, ймовірно, потрібно змінити WebApplication1 під час проекту проекту, який ви хочете перевірити). Якщо у вас неправильний шлях до web.config, копія не вдасться, і ви помітите це під час невдалої збірки.

Редагувати:

Щоб скопіювати з поточного проекту в тестовий проект:

copy "$(ProjectDir)bin\WebProject.dll.config" "$(SolutionDir)WebProject.Tests\bin\Debug\App.Config"

Це трохи старе, але я знайшов для цього краще рішення. Я намагався обрати відповідь тут, але схоже. .Strustrunconfig вже застарілий.

1. Для модульних тестів Wrap конфігурацією є інтерфейс (IConfig)

Для тестів Unit конфігурація дійсно не повинна бути частиною тестування, тому створюйте макет, який можна вводити. У цьому прикладі я використовував Moq.

Mock<IConfig> _configMock;
_configMock.Setup(config => config.ConfigKey).Returns("ConfigValue");
var SUT = new SUT(_configMock.Object);

2. Для тесту на інтеграцію динамічно додайте потрібну конфігурацію

Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
if(config.AppSettings.Settings[configName] != null)
{
    config.AppSettings.Settings.Remove(configName);
}
config.AppSettings.Settings.Add(configName, configValue);
config.Save(ConfigurationSaveMode.Modified, true);
ConfigurationManager.RefreshSection("appSettings");

Це дуже просто.

• Клацніть правою кнопкою миші на вашому тестовому проекті
• Додати -> Існуючий елемент
• Біля кнопки Додати ви можете побачити маленьку стрілку
• Виберіть файл конфігурації, натисніть "Додати як посилання"

Якщо ви використовуєте NUnit, погляньте на цю публікацію . В основному вам потрібно мати свою app.config у тому ж каталозі, що і ваш .nunit файл.

Якщо ваша програма використовує такі параметри, як Asp.net ConnectionString, вам потрібно додати атрибут HostType до вашого методу, інакше вони не завантажуються, навіть якщо у вас є файл App.Config.

[TestMethod]
[HostType("ASP.NET")] // will load the ConnectionString from the App.Config file
public void Test() {

}

Я використовую NUnit і в своєму каталозі проектів у мене є копія свого App.Config, що я змінюю певну конфігурацію (наприклад, я переспрямовую на тестову базу даних ...). Потрібно мати його в одному каталозі тестованого проекту, і ви будете добре.

Я не зміг змусити жодних із цих пропозицій працювати з nUnit 2.5.10, тому я в кінцевому підсумку скористався функцією Проект nUnit -> Редагувати, щоб вказати конфігураційний файл для націлювання (так як інші сказали, що він повинен знаходитися в тій же папці, що і. сам файл nunit). Позитивною стороною цього є те, що я можу надати конфігураційному файлу ім'я Test.config, що робить його набагато зрозумілішим, що це таке і чому це таке)

Ваші одиничні тести розглядаються як середовище, в якому працює ваш код, щоб перевірити його. Як і будь-яке нормальне середовище, у вас є інсценізація / виробництво. Вам може знадобитися також додати .configфайл для свого тестового проекту. Вирішення проблеми полягає у створенні бібліотеки класів та перетворенні її в Test Project, додавши необхідні пакети NuGet, такі як NUnit та NUnit Adapter. він ідеально працює як з Visual Studio Test Runner, так і з Resharper, і ви маєте свій app.configфайл у своєму тестовому проекті.

І нарешті налагодив мій тест та значення з App.config: