Тестирование контроллеров с помощью интеграционных тестов

Я работаю над проектом, который состоит из 3-х уровней: презентация (asp.net mvc) -> бизнес-логика -> репозиторий.

Мы тестируем все три части с помощью модульных тестов.

Планируем добавить интеграционные тесты. Теперь решаем, какую часть с ними тестировать.

Мы рассматриваем следующие решения:

  • Контроллеры тестирования, в этом случае будут задействованы все три части системы.
  • Протестируйте бизнес-логику, в этом случае будут задействованы всего 2 части

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

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

Спасибо.


integration-testing
person Anatoliy    schedule 06.12.2012    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

person Steve Wilkes    schedule 06.12.2012

arrow_upward
0
arrow_downward

business logic -> repository: Интеграционное тестирование необходимо, и здесь обнаружено множество критических ошибок. Многие ошибки, связанные с производительностью, также обнаруживаются на этом уровне путем выявления неверных запросов SQL.

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

Начните с написания тестов интеграции интерфейса, затем тестов контроллеров, а затем закодированного пользовательского интерфейса. Ручное тестирование должно происходить параллельно со всем этим.

person SarkarG    schedule 18.06.2013