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

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

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

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

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


automated-tests junit nunit
person djangofan    schedule 20.08.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

person martinnjensen    schedule 20.08.2009

arrow_upward
0
arrow_downward

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

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

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

person Gishu    schedule 20.08.2009