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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

Это Скромный Шаблон Диалогового Окна.

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

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

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

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

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

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

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

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

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

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