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

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

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

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

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

(Конечно, Wikipedia не является "авторитетом", но это звучит очень логично.)

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

Попробуйте комбинировать BDD с TDD.

BDD определяет сценарии как взаимодействие с gui (еще не реализовано)
пока есть "не реализованный BDD-шаг" (серый или красный)
- Преобразование некоторых не реализованных BDD-шагов текущего сценария в исполняемый код
- Внедрите этот шаг, используя tdd

Подробнее см. Разработка MSDN-статьи с помощью функций SpecFlow и WatiN. Хотя статья посвящена asp.net, идея является универсальной.