Как внедрить тестирование пользовательского интерфейса без головной бо

Автор: Gojko Adzic

Я сейчас пишу новую книгу и в связи с этим опрашиваю множество команд, внедривших приемочное тестирование. Большинство из уже опрошенных не в одном, так в другом месте наступали на грабли при автоматизации тестирования пользовательского интерфейса (UI). Пообщавшись несколько недель назад на Agile Acceptance Testing Days в Бельгии с некоторыми участниками, которые как раз опасно приблизились к тому месту, где спрятаны грабли, я хочу представить вашему вниманию хорошие, на мой взгляд, подходы к автоматизации UI-тестирования.

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

Читать дальше...

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

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

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

А можно поподробнее про эти вспомогательные средства? Как, скажем, при "текстовом программировании" добиться того, чтобы ошибки (скажем, опечатки) выявлялись не на этапе выполнения, а немедленно, на этапе разработки?

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

А можно поподробнее про эти вспомогательные средства? Как, скажем, при "текстовом программировании" добиться того, чтобы ошибки (скажем, опечатки) выявлялись не на этапе выполнения, а немедленно, на этапе разработки?

Самое простое - встроить spell-checker , особенно, если тестовые конструкции представлены в виде обычного plain-text.

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

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

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

А можно попдробнее про Cucumber? А то у нас обнаружение опечаток происходит аккурат при выполнении теста. Там можно реализовать проверку всего сценария на выполнимость перед непосредственным запуском на выполнение?

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

А можно попдробнее про Cucumber? А то у нас обнаружение опечаток происходит аккурат при выполнении теста. Там можно реализовать проверку всего сценария на выполнимость перед непосредственным запуском на выполнение?

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

Также, если есть ошибки компиляции, то по идее Cucumber среагирует на это

Это обработчик visit_step_result. Там надо проверить, что step_match.name равна :undefined и если это так, то вывести строку. Так мы узнаем, какие из инструкций не имеют реализаций. Хотя в поздних версиях могло что-то поменяться, идея та же самая.