При тестировании пользовательского интерфейса на основе MVC, какую настройку теста вы обычно используете?

Question

Я пытаюсь протестировать простой пользовательский интерфейс на основе WebForms (asp.net) и следовать шаблону MVP, чтобы мой пользовательский интерфейс был более тестируемым.

Следуя методологии TDD для бэкэнд-алгоритмов, я обнаружил, что существуют некоторые рефакторинги модульных тестов, которые происходят в духе принципа DRY (не повторяйте себя). Когда я пытаюсь применить это к пользовательскому интерфейсу, используя Rhino Mocks для проверки моих взаимодействий, я вижу много общего в тестах Controller при настройке представления или ожиданий модели.

Мой вопрос: как далеко вы обычно занимаетесь этим рефакторингом, если вообще? Мне любопытно посмотреть, как другие TDDer тестируют свои интерфейсы на основе MVC / MVP.

Answer 1

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

СУХОЙ не является проблемой испытаний.

Тем не менее, есть много сантехнических вещей, которые обычно делают, и они должны быть абстрагированы.

Answer 2

Я использую селен для функционального тестирования и я использую JUnit для проверки своих контроллеров.

Я макетирую службы или ресурсы, используемые контроллером, и проверю, на какой URI перенаправляет контроллер и т. Д.

Единственное, что я не проверяю в данный момент, это мнения. Но я использовал функциональное тестирование, чтобы компенсировать это.

Answer 3

Я бы предпочел рассматривать модульное тестирование как чисто функциональные программы, чтобы избежать необходимости их тестировать. Если операция достаточно часто встречается между тестами, я бы оценил ее для стандартной базы кода, но даже тогда я бы избегал рефакторинга тестов, потому что у меня их много, особенно для BL с графическим интерфейсом.

Answer 4

Я использую MVP, и в своих тестах я пытаюсь применить большую часть рефакторинга, как в стандартном коде. Обычно это не очень хорошо работает в тестах из-за небольших различий, необходимых для тестирования различных сценариев, но внутри частей может быть общность, и, по возможности, я объединяюсь. Это облегчает необходимые изменения позже по мере развития проекта; так же, как в вашем стандартном коде, проще поменять одно место вместо 20.