Использование Общего Конфигурационного Файла Для Unit Тестов В MS VS2005

Автор: Каргопольцев Дмитрий, Источник: http://it4business.ru/

Нашим отделом тестирования создаются тестовые проекты в одном общем решении (solution). Тестировщик ведёт один или более проектов. В каждом из них может быть свой конфигурационный файл. (Там могут быть, например, пути к эталонным файлам, ip адреса удалённых машин и т.п. - но пока не об этом)

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

Вопрос: Каким образом организовать доступ к конфиг файлу фреймворка?

Решение этого вопроса побудило написать пример с картинками.

В качестве примера рассмотрим solution MS VS2005, куда входит 2 проекта. (Разработка ведётся на C#. Используется Framework 2.0.)

Итак, проекты:
- FrameworkProject - библиотека, целью которой является объединение кода и настроек.
- UnitTestProject – собственно класс с тестами.


Решение UnitTestProject

Состав FrameworkProject:
FrameworkProject.dll.config – настройки, нужные для всех тестовых проектов.
Состав этого файла:


FWClass.cs - класс, в котором есть свойство ValueForAllTest позволяющее получить эти настройки.

Состав UnitTestProject:
App.config - файл, в котором имеются также настройки (задача - в будущем избавиться от этого файла).
Внутри него:

UnitTest.cs – класс с тестом … назовём его…, а пусть так и называется - TestMethod().

Добавим пару проверок, чтобы видеть результаты теста.

Примечание. Обычно 1 тест проверяет одно условие, но в данном примере я отошёл от этого правила, чтобы не “плодить” лишний код.

Хотим добиться, чтобы тест успешно завершился, т.е. получить запланированные значения Value1, Value2 из конфигурационных файлов.

Мотор, поехали!

Открываем TestManager, запускаем TestMethod и ….
Получили ошибку :

Failed TestMethod UnitTestProject Assert.AreEqual failed. Expected:, Actual:<(null)>.

Забавно, но факт! blush.gif
Тест видит конфигурационный файл только своего проекта UnitTestProject.
В переменную myKey попадают данные из файла App.config, а в переменной myKey2 сидит null.

Причина в том, что тест при вызове свойства FWClass.ValueForAllTest , доходя до строки внутри класса FrameworkProject,

вместо того, чтобы искать настройки в FrameworkProject.dll.config, ищет её в App.config
(ключа “CommonKey”, там нет впомине, правда, правда :))

Вывод - нужно "учить" тесты видеть нужный конфигурационный файл.

Шаг1.
Есть такая интересная функция ConfigurationManager.OpenExeConfiguration();
В качестве параметра задаётся существующая сборка и обещано легко найти её конфиг файл.

Переписываем свойство ValueForAllTest так:

Теперь при обращении к данному методу у нас:

  1. Вычисляется путь до сборки FrameworkProject.dll.
  2. По указанному файлу (согласно описанию функции OpenExeConfiguration) открывается указанный configuration файл, как Configuration объект.
  3. Забираем из него нужное значение.

Предупреждение.
Предварительно нужно сделать проверку на null для объекта element, иначе будет ошибка при попытке получить element.Value.

Запускаем тест и снова “красный” результат.
Забавно, но факт.
Получаем по прежнему в переменной myKey2 null. :)

Проблема в том, что FrameworkProject.dll ложится в папку …TestResultsOut…
Поэтому OpenExeConfiguration не находит по указанному пути конфигурационный файл.
А всё потому, что он должен лежать рядом со сборкой.

Вывод – нужно как то рядом со сборкой FrameworkProject.dll в папку out положить файл FrameworkProject.dll.config.

Варианты «ручками» или вычисления путей с дальнейшим копированием – отпадают, как неудобные.

Нам нужно красивое, автоматизированное решение!

Шаг2.
Вначале я попробовал в свойствах файла FrameworkProject.dll.config выставить значение Copy to Output Directory = Always.
Но это привело лишь к тому, что файл скопировался не в папку с результатами тестов, а в папку с билдами.

Кофе и общение с сотрудниками показали, что “собака зарыта” в файле localtestrun.testrunconfig.

Открываем файл, находим опцию Deployment и добавляем в список “Additional files and directories to deploy”, любимый FrameworkProject.dll.config.
Причём нужно добавлять его именно из папки с проектом, чтобы получился относительный путь
FrameworkProjectFrameworkProject.dll.config


Настройка конфигурации запускаемых тестов

Наконец, запускаем наш тест и с удовлетворением получаем “зелёный” свет.

Теперь можно смело удалять старые конфигурационные файлы, если они там лишние.

Исходники:



Опубликовал admin
19 Июл, Четверг 2007г.



Программирование для чайников.