Модульное тестирование веб-интерфейса

Question

Я недавно слышал дискуссию, в которой TDD было горячим модным словом. Теперь, по словам одного из ораторов, для тестирования вашего поведения вам нужно использовать MVC, но с другой стороны было сказано, что TDD - это подход, который может быть принят в любой среде (как обсуждение ASP.NET MVC или веб-форм). , Другой оратор заявил, что если вы поместите свое поведение в библиотеку или модели, то вы можете просто протестировать свой репозиторий или службы в TDD и, следовательно, не нужно беспокоиться о тестировании HTML. Сколько TDD должно покрывать в случае тестирования веб-интерфейса или стоит усилий?

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

EDIT

Я согласен с вами, ребята, и я тоже так чувствую: если вы действительно используете TDD, вам не нужно тестировать интерфейс веб-интерфейса, так как данные, которые вы ему предоставляете, должны находиться под вашим бизнесом / уровни сервисов / репозиториев, которые можно тестировать без пользовательского интерфейса. Поэтому, если вы запрограммируете свое приложение Web Forms таким образом, чтобы ваши операции / поведение были связаны с вызовами на стороне сервера (например, событиями нажатия кнопок, хотя в моем случае их можно проверить, вызывая операции более низкого уровня), вы можете иметь TDD в Web Forms , Спасибо за ваши ответы

Answer 1

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

У вас есть обе опции в ASP.Net с использованием ASP.Net MVC или WCSF (внедрение MVP с использованием веб-форм).

При этом вы все равно должны проводить тестирование GUI, но вам не нужно делать все это вручную. Selenium Server и Selenium Remote Control предлагают способы автоматического тестирования с помощью пользовательского интерфейса.

Answer 2

Я согласен с Джошем здесь. Просто продолжаю, так что я не могу проголосовать.

Во-первых, следует отметить, что тестирование вашего GUI не является модульным тестированием. При четком разделении интересов, как утверждал Джош, графический интерфейс не содержит бизнес-логики.

Логика, требующая тестирования, заключена в одну или несколько дискретных библиотек (или, возможно, в простые контроллеры MVC).

TDD относится только к блокам логического кода, и одним из отличительных признаков практической работы с TDD является то, что весь ваш логический код может быть написан и протестирован без какого-либо пользовательского интерфейса вообще. Фактически, тесты часто пишутся перед классами, которые они будут тестировать. Когда код завершен и все тесты пройдены, можно добавить пользовательский интерфейс, чтобы использовать созданные вами хуки API, и этот пользовательский интерфейс может быть веб-формами, MVC, WPF, winforms и т. Д.

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