Тестирование: Я *хочу* протестировать web.config
Я хочу сделать некоторое поблочное тестирование на одном из моих проектов. Это - веб-проект, и только будет одна копия этой программы, работающей кроме копий разработки.
Я хочу записать некоторые модульные тесты, которые будут использовать web.config. Я понимаю, что обычно, тестер погасил бы эту внешнюю зависимость, потому что он хочет протестировать код без теста в зависимости от web.config содержание определенных значений.
Однако web.config в моем проекте, как предполагается, всегда содержит определенные значения, и я хочу иметь модульный тест, который перестанет работать, если они будут установлены на недопустимые значения. Например, одно из значений является строкой подключения SQL.
Я хочу записать тест, который прочитает строку подключения из web.config. Я предполагаю это, тест мог соединиться с сервером со строкой подключения и возможно выполнить очень простую команду как SELECT system_user;. Если команда выполняется успешно и возвращает что-то тестовые передачи. Иначе это перестало работать. Я хочу, чтобы строка подключения была прочитана из web.config в проекте я тестирую.
Конечно, ConfigurationManager не будет обычно искать a web.config в другом проекте. Я мог вручную скопировать web.config от исходного проекта до тестового проекта, но я должен был бы сделать это перед каждым тестом и нет никакого способа, которым я мог рассчитывать на кого-либо еще, чтобы сделать это.
Как я делаю свое чтение тестового проекта web.config из другого проекта?
5 ответов
В проекте модульного тестирования добавьте файл app.config и добавьте настройки из файла web.config, которые вы хотите использовать для ваших тестов.
Вы можете загружать и исследовать другие файлы конфигурации с помощью методов ConfigurationManager.OpenXXX () .
В классе WebConfigurationManager есть специальный метод для открытия файлов web.config, а на странице документации, на которую я указал, есть еще несколько примеров кода. После загрузки объекта конфигурации вы можете исследовать его на предмет разделов и ключей.
var cfm = new ConfigurationFileMap("path/to/web.config");
var config = WebConfigurationManager.OpenMappedWebConfiguration(cfm);
Похоже, вы пытаетесь раздавить комара кувалдой. Почему бы не сделать это вручную, как часть контрольного списка развертывания; есть задача вручную подтвердить connectionString.
Или, если вы хотите автоматизировать это, напишите программу для проверки connectionString, присоедините ее к вашему серверу непрерывной интеграции (при условии, что он у вас есть) и завершите сборку, если connectionString неверно.
Используйте модульные тесты для того, что они предназначены для тестирования кода, а не для конфигурации.
Я задал аналогичный вопрос, который вы, возможно, захотите проверить:
Как мне проверить, что все мои ожидаемые настройки web.config были определены?
В конце концов он заработал, но досадная часть мой исходный элемент постоянно блокирует копируемый файл конфигурации. Вы также можете переименовать web.config в app.config, чтобы он скомпилировался в не веб-проект.
Похоже, вы пытаетесь проверить настройки в web.config , что является проблемой на уровне развертывания и отличается от модульного тестирования.
Модульное тестирование сообщает вам, что ваша основная логика работает должным образом; проверка развертывания сообщает вам, что приложение было установлено и настроено правильно и безопасно для использования. Модульные тесты важны для разработчиков, проверка развертывания важна для конечного пользователя или администратора, развертывающего приложение.
В такой ситуации мне нравится встраивать «системную консоль» в свои приложения. Эта консоль содержит ряд самодиагностических проверок, таких как:
- Обеспечение правильной настройки строки (строк) подключения
- Обеспечение доступности и работы любых сторонних служб
- Обеспечение того, что все параметры конфигурации действительны и не вызовет ошибок времени выполнения (например, существуют пути, учетная запись веб-пользователя имеет доступ для чтения / записи, где это необходимо, и т. д.)
Я настоятельно рекомендую вам рассмотреть возможность отделения такого рода проверки конфигурации и развертывания от вашего набора модульных тестов. Это не только упростит вашу работу (потому что у вас не будет для загрузки файла конфигурации из другого проекта), но и тот инструмент, который действительно очень нравится клиентам :)
{{1 }}