Применяется ли TDD при разработке пользовательского интерфейса?

Ответ 1

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

Аналогично, не тестируйте сами компоненты GUI, если только вы не пишете новые компоненты. Доверяйте структуре, чтобы выполнять свою работу.

Вместо этого вы должны тестировать поведение, лежащее в основе этих компонентов: контроллеры и модели, составляющие ваше приложение. Использование TDD в этом случае приводит вас к разделению проблем, так что ваша модель действительно является объектом управления данными, а ваш контроллер действительно является объектом поведения, и ни один из них не тесно связан с пользовательским интерфейсом.

Ответ 2

Я смотрю TDD с точки зрения пользовательского интерфейса больше из голых критериев приемлемости для пользовательского интерфейса. В некоторых кругах это обозначается как ATDD или Acceptance Test Driven Development.

Самая большая надстройка, которую я нашел в использовании TDD для пользовательских интерфейсов, - это когда я все взволновался об использовании автоматических тестов для проверки проблем с внешним видом. Мой совет: не надо! Сосредоточьтесь на тестировании поведения: этот клик создает эти события, эти данные доступны или отображаются (но не отображаются). Look and Feel действительно является областью вашей независимой группы тестирования.

Ключ состоит в том, чтобы сфокусировать свою энергию на действиях "Высокая добавленная стоимость". Автоматизированные тесты стиля - это скорее долг (поддерживающий их актуальность), чем добавление стоимости.

Ответ 3

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

Ответ 4

Я не могу говорить с Microsoft Silverlight, но я никогда не использую TDD для каких-либо проблем с макетом, просто не стоит времени. Что хорошо работает, это использование Unit Testing для проверки любого типа проводки, проверки и логики пользовательского интерфейса, которые вы внедрили. Большинство систем предоставляют вам программный доступ к действиям, которые предпринимает пользователь, вы можете использовать их, чтобы утверждать, что ваши ожидания правильно выполнены. Например. вызов метода click() на кнопке должен выполнять любой код, который вы намеревались. Выбор элемента в представлении списка изменяет содержимое всех элементов пользовательского интерфейса на эти свойства элементов...

Ответ 5

Основываясь на вашем редактировании, немного подробнее о том, как мы это делаем в моей текущей команде. Я делаю Java с GWT, поэтому приложение Silverlight может быть немного выключено.

Требование или ошибка приходит к разработчику. Если есть изменение пользовательского интерфейса (L & F), мы делаем быстрый макет изменения пользовательского интерфейса и отправляем его владельцу продукта для утверждения. Пока мы ждем этого, мы начинаем процесс TDD.

Мы начинаем, по крайней мере, с веб-теста (используя Selenium для управления кликами пользователей в браузере) или "безгласных" функциональных тестов с использованием Concordion, FiT или что-то в этом роде. После того, как это было сделано и не удалось, у нас есть вид на высоком уровне, где можно атаковать базовые службы, чтобы система работала правильно.

Следующий шаг - выкапывать и записывать некоторые неудачные тесты на единицу и интеграцию (я думаю, что модульные тесты являются автономными, без зависимостей, без данных и т.д. Тесты интеграции - это полностью проводные тесты, которые читают/записывают в базу данных, и др.)

Затем я заставляю его работать снизу вверх. Похоже, ваш фон TDD позволит вам экстраполировать преимущества здесь. Рефакторинг на пути вверх, а также....

Ответ 6

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

Тестирование пользовательского интерфейса, например, является общим место, где это просто не стоит времени и усилий.

...

Качество кода, гибкость и способность к изменению - это другие вещи которые часто приписываются испытаниям. Они, безусловно, помогают, но они не означает, что единственное (или даже лучшее) способ приблизиться к этому.

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

Обратите внимание: кажется, что сообщение в основном связано с тестированием ПОСЛЕ того, что были созданы, а не ДО (как в TDD) - но я думаю, что следующее золотое правило все еще применяется: самые важные вещи заслуживают наибольших усилий и менее важных вещей заслуживают меньшего усилия. Наличие тестируемого UI-модуля часто не так важно, и, как пишет Айенде, преимущество использования TDD в качестве модели разработки, вероятно, не так велико, особенно если вы думаете, что разработка пользовательского интерфейса обычно является процессом сверху вниз.

Ответ 7

GUI по самой своей природе трудно проверить, так как Брайан Расмуссен предлагает сохранить код диалогового окна отдельно от кода GUI.

Это шаблон Humble Dialog Box.

Например, у вас может быть диалоговое окно, в котором вводятся данные (например, номер кредитной карты), и вам необходимо их проверить. Для этого случая вы поместите код, который проверяет номер кредитной карты с помощью алгоритма Luhn в отдельный объект, который вы тестируете. (Этот алгоритм просто проверяет, является ли число правдоподобным - он предназначен для проверки ошибок транскрипции.)

Ответ 8

На моем рабочем месте мы используем TDD и фактически unit test наш код пользовательского интерфейса (для веб-приложения) благодаря Apache Wicket WicketTester, но он не тестирует, что какая-либо описательная метка находится перед текстовым полем или что-то в этом роде, вместо этого мы проверяем, что иерархия компонентов несколько правильна ( "метка находится в том же подмножестве, что и текстовое поле" ), а компоненты - это то, что они должны быть ( "этот ярлык действительно является меткой" ).

Как уже говорили другие, это касается реального человека, чтобы определить, как эти компоненты размещаются в пользовательском интерфейсе, а не программиста, тем более, что у программистов есть тенденция делать все-в-одном/неясные инструменты командной строки вместо UI, которые просты в использовании.

Ответ 9

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

Лично я не уверен, как вы собираетесь выполнять TDD для пользовательского интерфейса; однако команда, на которой я работаю, выполняет автоматизированные имитационные тесты наших пользовательских интерфейсов. В принципе, у нас есть набор симуляций, которые запускаются каждый час в самой последней версии приложения. Эти тесты выполняют общие действия и проверяют, что определенные элементы, фразы, диалоги и т.д. И т.д. Должным образом происходят на основе, скажем, набора вариантов использования.

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

Некоторые тесты лучше, чем тестирование, но это может быть лучше.

Ответ 10

Да, вы можете использовать TDD с большим эффектом для тестирования веб-приложений GUI.

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

Это действительно опрятно для того, чтобы поймать те вещи, которые тестеры всегда забывают щелкнуть; они тоже испытывают слепоту!