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

Question

Как вы оцениваете использование TDD при разработке пользовательского интерфейса?

Я долго размышлял над этим вопросом и просто не могу прийти к окончательному решению. Мы собираемся запустить проект Silverlight, и я проверил Microsoft Silverlight Unit Test Framework с учетом TDD, но я не уверен, как применить подход к разработке пользовательского интерфейса вообще - или к Silverlight в частности.

EDIT: Вопрос заключается в том, целесообразно ли использовать TDD для разработки пользовательского интерфейса, а не в том, как сделать разделение задач.

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

...

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

Answer 8

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

Это шаблон диалогового окна Humble .

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

Answer 9

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

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

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

Answer 10

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

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

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

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