Разработка через тестирование (TDD) для пользовательского интерфейса (UI) с функциональными тестами

Question

Как мы знаем, TDD означает «сначала напиши тест, а потом напиши код». И когда дело доходит до юнит-тестирования, это нормально, потому что вы ограничены "юнитом".

Однако, когда дело доходит до пользовательского интерфейса, написание функциональных тестов заранее не имеет смысла (для меня). Это связано с тем, что функциональные тесты должны проверять (возможно, длинный) набор функциональных требований. Обычно это может охватывать несколько экранов (страниц), предварительные условия, такие как «вход в систему», «недавно вставленная запись» и т. Д.

Согласно Википедии:

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

(Конечно, Википедия не является «авторитетом», но это звучит очень логично.)

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

Answer 1

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

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

Answer 2

Ключом к тестированию пользовательского интерфейса является разделение ваших проблем - поведение вашего пользовательского интерфейса фактически отличается от внешнего вида вашего пользовательского интерфейса. Мы мысленно боремся с этим, поэтому в качестве упражнения возьмем игру, подобную тетрису, и представим, что она переносится с одной платформы (скажем, ПК) на другую (в Интернете). Интуиция в том, что все по-другому - нужно все переписать! Но на самом деле все это одно и то же:

• Правила игры.
• Скорость падения блоков.
• Логика для сопоставления строк
• Какой блок выбран
• И еще ...

Вы поняли идею. Единственное, что меняется, это то, как нарисован экран. Так что отделите, как ваш интерфейс выглядит от того, как он работает Это сложно, и обычно не может быть идеальным, но это близко. Моя рекомендация - написать последний интерфейс. Тесты предоставят обратную связь, если ваше поведение работает, и экран покажет, выглядит ли он правильно. Эта комбинация обеспечивает быструю обратную связь, которую мы ищем от TDD без пользовательского интерфейса.

Answer 3

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

Вот рабочий процесс, предложенный в книге Разработка через тестирование на Python Гарри Персивалем (доступно онлайн бесплатно):

P.S. Вы можете автоматизировать свои функциональные тесты, например, с помощью Селен. Вы можете добавить их в цикл непрерывной интеграции, а также в модульные тесты.

Answer 4

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

Самая большая проблема с выполнениемэто, конечно, чаще всего пользовательский интерфейс не полностью выделен.

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

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

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

Answer 5

Программные тесты пользовательского интерфейса - это спасение, если вы хотите быть уверены, что ваш пользовательский интерфейс делает то, что ожидалТесты пользовательского интерфейса ближе к BDD (поведенческая разработка), чем к TDD.Но терминология неясна, и как бы вы их ни называли, они полезны!У меня довольно хороший опыт использования огурца .Я использую его для тестирования приложений Flex, но в основном он используется для тестирования веб-приложений.Нажмите на ссылку!На сайте есть действительно хорошие примеры методологии.

Answer 6

Я сделал TDD Acceptance с пользовательским интерфейсом.Мы бы утверждали, что общий заголовок и нижний колонтитул использовались через xpath'ing для соответствующих идентификаторов.Мы также использовали xpath для подтверждения того, что данные отображаются в правильном теге относительно идентификаторов, которые мы использовали для базовой компоновки и структуры.Мы также утверждаем, что выходная страница является верной HTML 4.01 строго.

Answer 7

Попробуйте объединить BDD с TDD.

• BDD определяет сценарии как взаимодействие с графическим интерфейсом (еще не реализовано)
• , в то время как существует «не реализованный BDD-шаг» (серый иликрасный)
  • Преобразовать некоторые не реализованные BDD-шаги текущего сценария в работающий код
  • Реализуйте этот шаг, используя tdd

.подробности см. Разработка, основанная на поведении MSDN, с SpecFlow и WatiN .Несмотря на то, что статья о asp.net, идея универсальна.