Unit Testing the Web GUI

Question

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

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

EDIT:

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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