TDD применяется хорошо при разработке UI?
Полная версия Удалить emojis:
def remove_emoji(string):
emoji_pattern = re.compile("["
u"\U0001F600-\U0001F64F" # emoticons
u"\U0001F300-\U0001F5FF" # symbols & pictographs
u"\U0001F680-\U0001F6FF" # transport & map symbols
u"\U0001F1E0-\U0001F1FF" # flags (iOS)
u"\U00002702-\U000027B0"
u"\U000024C2-\U0001F251"
"]+", flags=re.UNICODE)
return emoji_pattern.sub(r'', string)
10 ответов
Попытка протестировать точное размещение компонентов UI бессмысленна. Сначала, потому что расположение субъективно и должно быть "протестировано" людьми. Во-вторых, потому что, поскольку UI изменяется, Вы будете постоянно переписывать свои тесты.
Точно так же не тестируют сами компоненты графического интерфейса пользователя, если Вы не пишете новые компоненты. Доверяйте платформе, чтобы сделать ее задание.
Вместо этого необходимо тестировать поведение, которое лежит в основе тех компонентов: контроллеры и модели, которые составляют Ваше приложение. Используя TDD в этих дисках случая Вы к разделению проблем, так, чтобы Ваша модель была действительно объектом управления данными и Вашим контроллером, являетесь действительно объектом поведения, и ни один из них не сильно связывается к UI.
Я смотрю на TDD с точки зрения UI больше от пустых критериев допустимости для UI для передачи. В некоторых кругах это маркируется как ATDD или Приемочное испытание Управляемая Разработка.
Самая большая сверхразработка я нашел в использовании TDD для UIs, когда я стал все взволнованным использованием автоматизированных тестов для тестирования проблем стиля. Мой совет: не делайте! Внимание на тестирование поведения: этот щелчок производит эти события, эти данные доступны или отображены (но не, как это отображено). Стиль действительно является доменом Вашей независимой команды тестирования.
ключ должен сфокусироваться, Ваша энергия на "Высоком Значении Добавляют" операции. Автоматизированные тесты стиля являются большим количеством долга (держание в курсе их), чем значение добавляет.
При разделении Вас логика от фактического кода GUI можно легко использовать TDD для создания логики, и будет намного легче создать другой интерфейс сверху логики также, если Вам когда-либо будет нужно это.
Я не могу говорить с Microsoft Silverlight, но я никогда не использую TDD ни для какого вида проблем расположения, просто не стоит времени. Что работы хорошо использует Поблочное тестирование на проверку любого вида проводного соединения, проверки и логики UI, которую Вы реализовали. Большинство систем предоставляет Вам программный доступ к мерам, которые принимает пользователь, можно использовать их, чтобы утверждать, что надежды правильно оправданы. Например, называя щелчок () метод на кнопке должен выполнить то, что когда-либо кодирует Вас предназначенный. Выбор объекта в представлении списка изменяет все содержание элементов UI на это свойства объектов...
На основе Вашего редактирования вот немного больше детали о том, как мы делаем это в моей текущей команде. Я делаю Java с GWT, таким образом, приложение к Silverlight могло бы быть немного выключено.
Требование или ошибка входят разработчику. Если существует изменение UI (L& F) мы приводим в порядок быструю насмешку для изменения UI и отправляем его владельцу продукта для одобрения. В то время как мы ожидаем на этом, мы запускаем процесс TDD.
Мы запускаем с, по крайней мере, на любого веб-тест (использующий Селен для управления пользовательскими щелчками в браузере), или "бездисплейное" использование функционального испытания Concordion, FiT или что-то как он. После того как это сделано и сбой, у нас есть видение высокого уровня того, где напасть на базовые сервисы, чтобы заставить систему работать правильно.
Следующий шаг должен копнуть и записать некоторую провальную единицу и интеграционные тесты (я думаю о модульных тестах как автономных, никакие зависимости, никакие данные, и т.д. Интеграционные тесты полностью соединены проводом тесты, от которых чтения-записи к базе данных, и т.д.)
Затем я заставляю его работать вверх дном. Кажется, что Ваше образование TDD позволит Вам экстраполировать преимущества здесь. Осуществите рефакторинг на пути также....
Я думаю , это сообщение в блоге Ayende Rahien отвечает на мой вопрос приятно с помощью прагматического и звукового подхода. Вот несколько кавычек из сообщения:
Тестирование UI, например, является общим местом, где это просто не стоит времени и усилия.
...
качество Кода, гибкость и способность измениться являются другими вещами, которые часто приписываются тестам. Они, конечно, помогают, но они - значительным единственное (или даже лучшее) способ приблизиться к этому.
Тесты должны только использоваться, когда они увеличивают стоимость проекта, не становясь основным вниманием. Я наконец совершенно уверен, что использующий разработку через тестирование для UI может быстро стать источником большой работы, которая просто не стоит того.
Примечание, что это кажется сообщением, главным образом о тестировании ПОСЛЕ ТОГО, КАК вещи были созданы, не ПРЕЖДЕ (как в TDD) - но я думаю, что следующее золотое правило все еще применяется: самые важные вещи заслуживают самого большого усилия, и менее важные вещи заслуживают меньшего усилия. Наличие протестированного на единицу UI часто не НАСТОЛЬКО важно, и как Ayende пишет, преимущество использования TDD, поскольку модель разработки является, вероятно, не настолько замечательной - особенно при размышлении о той разработке UI, обычно нисходящий процесс.
Графический интерфейсы пользователя по самой своей природе трудно протестировать, поэтому как Brian Rasmussen предполагает, разделяют код диалогового окна от код GUI.
Это Скромный Шаблон Диалогового окна .
, Например, у Вас может быть диалоговое окно, где детали (например, номер кредитной карты) вводятся, и необходимо проверить их. Для этого случая Вы поместили бы код, который проверяет номер кредитной карты с алгоритм Luhn в отдельный объект, который Вы тестируете. (Рассматриваемый алгоритм просто тестирует, если число вероятно - это разработано для проверки ошибки записи.)
На моем рабочем месте мы используем TDD и нас на самом деле тест единицы наш код UI (для веб-приложения) благодаря Калитка Apache WicketTester, но это не тестирует ту некоторую описательную маркировку, перед текстовым полем или чем-то как этот, вместо этого мы тестируем ту иерархию компонентов, несколько корректно (" , маркировка находится в том же подмножестве как текстовое поле "), и компоненты - то, что они, как предполагается, (" , эта маркировка действительно маркировать ").
Как другие уже сказали, это до живого человека, чтобы определить, как те компоненты помещаются в UI, не программиста, тем более, что у программистов есть тенденция выполнения все в одном/неясный инструментов командной строки вместо UIs, которые просты в использовании.
Разработка через тестирование предоставляет себя больше разработке кода, чем для разработки пользовательских интерфейсов. Существует несколько различных путей, которыми выполняется TDD, но предпочтительный способ истинного TDD состоит в том, чтобы записать Ваши тесты сначала, затем написать код, чтобы пройти тесты. Это сделано многократно в течение разработки.
Лично, я не уверен в том, как Вы пошли бы о выполнении TDD для UI; однако, команда, что я иду, выполняет автоматизированные испытания методом моделирования нашего UIs. В основном у нас есть комплект моделирований, которые выполняются каждый час на новой сборке приложения. Эти тесты выполняют общие действия и проверяют, что определенные элементы, фразы, диалоговые окна, и т.д., и т.д., правильно происходят на основе, скажем, ряда вариантов использования.
, Конечно, это действительно имеет его недостатки. Оборотная сторона к этому - то, что моделирования заблокированы в код, представляющий случай. Это оставляет мало места для различия и в основном говорит, что ожидает, что пользователь сделает точно это поведение относительно этой функции.
Некоторое тестирование не лучше, чем никакое тестирование, но это могло быть лучше.
Да, можно использовать TDD с большим эффектом для тестирования GUI веб-приложений.
При тестировании GUI Вы обычно используете тупиковые/поддельные данные, которые позволяют Вам протестировать все различные изменения состояния в своем gui. Необходимо разделить бизнес-логику от gui, потому что в этом случае Вы захотите дразнить свою бизнес-логику.
Это действительно аккуратно для ловли тех вещей, на которые тестеры всегда забывают нажимать; они заболели тестовой слепотой также!