Автоматизация UI-тестирования следующего поколения

Автоматизация UI-тестирования следующего поколения Иван Иноземцев Xored Я практически не знаю людей, имевших положительный опыт использования инструментов для автоматического тестирования UI. Все эти системы крайне неудобны в использовании и имеют достаточно высокий порог вхождения -- от момента "скачал" до "встроил в nightly builds" могут пройти месяцы. Вдобавок, получившиеся в итоге тесты -- жутко громоздкие, медленные и нестабильные -- тяжело поддерживать и интерпретировать. В результате отстойность инструментов бросает тень на весь подход -- забраковывается сама идея полезности автоматического UI-тестирования. В 2011м году мы выпустили наш продукт для UI-тестирования, который может тестировать приложения только на базе одной платформы -- Eclipse. Отказ от "поддержки" всех мыслимых фреймворков позволил сделать нам инструмент, работающий на качественно другом уровне. Наши пользватели думают что попадают в страну эльфов, где записанные действия проигрываются как есть, тесты легко создавать и поддерживать, а падения одного теста не могут "уронить" последующие. В докладе хотелось бы коротко рассказать о следующем: - Проникновение в тестируемое приложение. Мы модифицируем запуск приложения, добавляя туда пачку наших плагинов и инструментируя классы фреймворка, тем самым имея возможность знать практически все о происходящем внутри приложения. - Разделение описания состояния (декларативно) и выполняемых действий (императивно). - Запись пользовательских действий. Как из потока UI-событий понять действия пользователя и описать их в виде высокоуровневых команд. - Свой DSL. Язык описания действий должен быть легко читаем всеми и обладать достаточной выразительной мощью. - Воспроизведение. Как понять что команда завершила работу и можно исполнять следующую. - А что делать когда тестов много? На дворе 2010-е, переходим в облако!