Привет! Сегодня - обещанный еще неделю назад (shame on me) пост про концепцию шагов в авто-тестах и их использование в Allure.
Откуда ноги растут
Если ты давно занимаешься автоматизацией, то наверняка знаком с такими фреймворками как FitNesse или Cucumber. Подобные фреймворки продаются как возможность писать тесты кому угодно в виде бизнес-требований в текстовом формате. Такие словесные требования образуют DSL тестируемого приложения. Дальше пишется прослойка, которая интерпретирует текст в исполняемый код, матчит полученный код с текстовым описанием и отображает результаты выполнения этого кода.
Кроме упомянутых выше фреймворков, я видел бесчисленное множество велосипедов, реализующих эту идею. Однако, я не знаю ни одного проекта, в котором в итоге тесты писали бы не технические люди. С одной стороны, получается, что подход не выполняет свою основную задачу - избавить автоматизаторов от необходимости погружаться в контекст тестируемого приложения. С другой стороны, он имеет ряд неоспоримых достоинств:
- код тестов и их описание (документация) неразрывно связаны - за их изменением проще следить, меньше вероятность их расхождения и устаревания
- тесты, написанные в терминах DSL, получаются простыми и понятными
- наличие еще одного уровня абстракции (DSL) положительно сказывается на архитектуре тестового фреймворка, уменьшая время поддержки и написания новых тестов
Убираем лишнее, оставляем полезное
Джон Смарт со своим Thucydides решил не заставлять людей писать тесты простым текстом. Всё равно ведь не-автоматизаторы этого не делают, а автоматизаторы это не любят (они любят писать код). Вот он и ограничился DSL на уровне кода. Для этого он ввёл понятие тестового шага.
Шаг - это атомарное действие, которое пользователь может сделать в приложении (перейти по ссылке, ввести текст и т.п.). С точки зрения программирования, шаг - это особым образом аннотированный метод. Его задача - скрыть особенности взаимодействия с приложением, упростив тем самым содержание теста до последовательности шагов. Шаги могут содержать в себе другие шаги. Например, чтобы выполнить шаг “залогиниться” - нужно выполнить три шага: вбить логин, пароль и нажать кнопку “войти”. В большинстве случаев, нам не интересны такие подробности, поэтому мы используем в тестах шаг “залогиниться”. Набор таких шагов образует DSL тестируемого приложения, который позволяет сохранить преимущества фреймворков описанных выше - простые тесты и удобство поддержки.
Чтобы не потерять и третье, самое важное приимущество (неразрывность кода тестов и его описания) - после выполнения тестов генерируется отчёт, в котором те же шаги что и в тесте, только в виде привычной простому смертному html-странички.
Шаги в Allure
Так что же нужно сделать чтобы начать пользоваться шагами в Allure? Да почти ничего (если ты уже подключил Allure к своему проекту). Вот так будет выглядеть в терминах шагов простой тест - зайти на яндекс и поискать по слову allure.
После выполнения такого теста Allure сгенерирует отчёт, в котором будут ровно те же шаги. Сам класс с шагами тоже довольно примитивный. Всё, что нужно, чтобы метод стал шагом - аннотировать его как @Step:
- Добавь сюда рулы, чтобы управлять webdriver’ом и собирать необходимую информацию по ходу выполнения или в случае падения теста
- Добавь сюда PageObject’ы с HtmlElements чтобы отделить интерфейс приложения от сценариев работы с ним
- Перестань разбирать отчёты (теперь их может понять любой, тебе незачем работать переводчиком)
- …
- Профит!