Каков наилучший метод для хранения тестовых случаев, из которых загружаются ваши тесты xunit?

Question

Это вопрос "дизайн / архитектура", поэтому вам не нужно предоставлять мне технические детали.

Я могу найти примеры в Интернете в течение всего дня, которые показывают, как запустить модульный тест xunit, записать результаты тестов и как показать, если он успешен или неуспешен, но каждый пример в Интернете жестко запрограммирован, и никто не показывает примеров как вы эффективно сохраняете свои тестовые наборы (nunit или junit), позволяя создавать сотни или тысячи тестов и загружать их в ваш механизм тестирования.

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

Возможно, опишите свой ответ в контексте выполнения модульных тестов на странице "Расширенный поиск Google", на которой есть много вариантов, сотни вариантов и т. Д.

Answer 1

Я согласен с тем, что здесь важно сохранять простоту и позволить ей расти «естественно». Тесты так же важны, как и ваш другой код, и должны быть реорганизованы так же энергично.

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

Функция RowTest действительно хороша для простых сценариев, но если вы имеете дело со сложными сценариями, вам следует обратиться к шаблону Test Data Builder , который позволяет определять сценарии по умолчанию, а затем их варианты.

Мне нравится держать мои тестовые данные как можно ближе к тестам, что позволяет мне реально видеть, что происходит в тестах. Поэтому я не думаю, что вопрос заключается в том, следует ли вам использовать XML или базу данных, это просто разные форматы представления данных, но действительно ли вы хотите отделить свои тестовые данные от своих тестов?

Answer 2

Если вы переходите к «тестам на основе данных», вам следует взглянуть на подход RowTest и его эквиваленты. NUnit позаимствовал это у MBUnit. xUnit, кажется, имеет еще более расширяемое решение для этого через Theory и PropertyData , где вам не нужно указывать входные данные в коде; Вы можете генерировать входные данные из произвольной функции, электронной таблицы или базы данных SQL Server.

У меня никогда не было необходимости в чем-либо, кроме метода Rowtest (который также редок) ... поэтому я не могу предупредить вас о каких-либо драконах. В качестве альтернативы вы можете даже использовать Fit / Fitnesse, чтобы сделать это, если вы не можете сделать вышеупомянутые подходы; хотя технически это не приемочное испытание.

Что касается «среды тестирования», может быть, YAGNI, а вы. Начните, начните с малого, сделайте это простым, со временем вырастите дизайн теста.