В этой статье мы расскажем, как с помощью IntelliJ IDEA Agile-команды могут управлять тест-кейсами и поддерживать их синхронизацию с автоматическими тестами и функциональными ветками. Подход, которого мы придерживаемся, можно более точно описать как «Test as Text» или «Test as Code». Он предполагает хранение тест-кейсов в простом текстовом формате, желательно в системе контроля версий рядом с кодом проекта. Это позволяет нам управлять сценариями тестирования прямо из IDE, синхронизировать их с автоматическими тестами, просматривать историю изменений и разрабатывать тестовые сценарии одновременно с новыми функциями.
Если вы захотите попробовать, то всё, что вам понадобится, — это IntelliJ IDEA Community Edition и Test Management плагин.
Подготовка тест-кейсов
Представим, что в нашей Agile-команде разработчики активно работают над новой фичей в отдельной ветке. Как QA-инженеры, мы должны заранее подготовить сценарии тестирования и чеклисты, чтобы быть готовыми к тестированию.
Конепция Test as Text предусматривает, что тест-кейсы были написаны в простом, подходящем для текстового редактора формате и по возможности использовалась система контроля версий. Выберем папку, в которую мы хотим положить тестовые сценарии, и создадим новый тест-кейс.
В контекстном меню выберем New Test Case и дадим ему название. IDE создаст markdown-файл с примером текста.
![New Test Suite в контекстном меню New Test Suite в контекстном меню](https://habrastorage.org/getpro/habr/upload_files/413/213/a6e/413213a6ed1705927ec84848d7e6bfbe.png)
Хотя содержимое файла — чистый Markdown, обратите внимание на необычное расширение .t.md. Оно указывает на то, что файл предназначен для хранения тестовых сценариев.
![Markdown-файл с примером тест-кейса Markdown-файл с примером тест-кейса](https://habrastorage.org/getpro/habr/upload_files/c7f/c82/e42/c7fc82e42ca4d42d7f5a36b59804a423.png)
Как видно из примера, формат файла довольно прост. В маркдауне заголовок — это название набора тестов (чеклиста), а пункты списка — названия проверок или тест-кейсов. Если нужно разбить тест-кейс на несколько шагов, добавьте вложенный список. IntelliJ IDEA поможет отличать тест-кейсы от шагов, помечая их соответствующими значками на полях.
Давайте определим пару тест-кейсов, которые будут описывать новую функциональность, разрабатываемую в этой ветке. Мы также можем задать для этих тестов некоторые теги и метаинформацию.
![Тестовые сценарии Тестовые сценарии](https://habrastorage.org/getpro/habr/upload_files/c1f/62e/ca5/c1f62eca50c0ae23d34452b28888a119.png)
Когда все готово, отправим наши результаты в VCS, чтобы их увидели коллеги по команде.
В окне TMS можно просматривать и фильтровать существующие и свежесозданные тест-кейсы. Чтобы быстро перейти к сценарию тестирования, воспользуемся поиском Search Everywhere и введем имя теста. Для фильтрации результатов можно использовать префикс /tms или перейти к Navigate | TMS item из главного меню.
![Тестовые сценарии в окне Search Everywhere Тестовые сценарии в окне Search Everywhere](https://habrastorage.org/getpro/habr/upload_files/83d/601/519/83d601519c10d52c96c2fd5726759983.png)
Выполнение проверок и хранение результатов
Когда мы создали тест-кейсы для новой функциональности, можно приступать к выполнению проверок, как только разработчики будут готовы.
Выберите New Test Run в контекстном меню (в нашем примере мы сделаем это в папке, где хранятся наши тест-кейсы) и дайте ему имя. Затем выберите тесты, которые нужно выполнить, и подтвердите свой выбор.
![New Test Run в контекстном меню New Test Run в контекстном меню](https://habrastorage.org/getpro/habr/upload_files/a20/772/a69/a20772a69f95a1483a9483ed08814116.png)
IDE создаст markdown-файл, на этот раз с расширением «.r.md», указывающим на то, что файл используется для хранения результатов выполненных проверок.
![Незавершённый Test Run Незавершённый Test Run](https://habrastorage.org/getpro/habr/upload_files/07d/5d6/e9a/07d5d6e9afd915420714329c21ef8f5e.png)
Шаги для тестовых сценариев копируются в тест-ран, и по умолчанию каждый сценарий имеет статус «unknown». Название теста должно быть оформлено как заголовок в Markdown. IntelliJ IDEA помечает каждый тест и его результаты значками на левом поле и подсвечивает их в редакторе.
Как только мы выполним проверку, можно записать результаты и заменить статус «unknown» на стандартные «success» или «fail» либо выбрать для индикации любое другое слово. Можно использовать любой статус, о котором вы договоритесь с командой, без дополнительных настроек. Иногда требуется отойти от тестового сценария или указать подробности выполненных действий. Мы можем сделать это, изменив описание шагов в соответствующем тесте.
![Test Run cо статусами прохождения тестов Test Run cо статусами прохождения тестов](https://habrastorage.org/getpro/habr/upload_files/f24/c64/bee/f24c64bee1c19c9ed8b848d1e4a4f32e.png)
Наш тест-ран также отображается в окне TMS. Когда мы закончим, можем закоммитить результаты проверок (файл тест-рана) в VCS и поделиться ими с командой.
Создание автотеста
По мере того, как мы приближаемся к заключительным этапам имплементации функции, приходит время автоматизировать хотя бы некоторые из наших тестов.
IntelliJ IDEA может нам в этом помочь несколькими способами. Откроем класс юнит-теста, в который хотим добавить новый автотест.
Затем в окне TMS найдем тест-кейс, который хотим автоматизировать. Чтобы просмотреть все неавтоматические тесты, откроем диалог Filtering и попросим IDE показать только те тест-кейсы, на которые нет ссылок в коде. Поскольку мы еще не автоматизировали свежесозданные тест-кейсы, все они отобразятся в окне TMS.
![Редакто фильтров в тул-окне TMS Редакто фильтров в тул-окне TMS](https://habrastorage.org/getpro/habr/upload_files/9a0/ed3/4f5/9a0ed34f5d4f8a8e25a42827c7cc0cc7.png)
Скопируем нужный тест с помощью шортката или через контекстное меню и вставим его в класс юнит-теста.
![Тестовые сценарии не имеющие соответствуюзих авто-тестов Тестовые сценарии не имеющие соответствуюзих авто-тестов](https://habrastorage.org/getpro/habr/upload_files/cb1/66d/299/cb166d2992e742cb37c90b239686bfc5.png)
IntelliJ IDEA добавит шаблон тестовой функции с соответствующим именем и всеми предварительно настроенными Java-аннотациями. Тело функции будет содержать шаги тестового сценария в виде комментария к коду. Теперь все готово к реализации автоматизированных тестов.
![Тестовый сценарий, который был скопирован в java класс и больше не отображается в TMS окне в соответствии с правилами фильтрации Тестовый сценарий, который был скопирован в java класс и больше не отображается в TMS окне в соответствии с правилами фильтрации](https://habrastorage.org/getpro/habr/upload_files/83d/636/332/83d636332bbf80c765b6c51b36cb3c2e.png)
Этот тестовый сценарий больше не отображается в окне TMS, поскольку теперь на него есть ссылка в коде.
Мы можем перейти к объявлению сценария, кликнув по ссылке в комментариях или по нашей аннотации TmsLink. Когда имплементация фичи будет завершена, наша команда смержит ее с основной веткой.
Список сценариев тестирования и выполненных проверок можно рассматривать как отчет о качестве новой фичи, и мы можем впоследствии использовать сценарии для регрессионных проверок и автоматизации тестирования.
Как попробовать
Установите плагин Test Management в вашу IDE JetBrains. Вы можете просматривать и редактировать тест-кейсы в любой поддерживаемой IDE JetBrains, но интеграция с юнит-тестами сейчас работает только для Java, Kotlin и Python (в IntelliJ IDEA Community Edition и PyCharm Community Edition).
В официальной документации вы найдете информацию о том, как включить Local TMS (Test as Text), настроить пользовательские Java-аннотации и Python-декораторы в качестве TMS-ссылок, а также как настроить шаблоны для генерации кода.
Вот тут вы можете ещё раз просмотреть краткий обзор всех возможностей.
Заключение
Подход Test as Text помогает нам быть более гибкими в работе с тестовыми сценариями, поскольку мы можем разрабатывать тесты и выполнять проверки параллельно с разработкой функциональности. Поскольку в системе контроля версий все хранится в одном проекте, мы видим историю изменений, а у разработчиков есть доступ к тестовым сценариям для отладки. Такой подход отвечает потребностям Agile-команд и повышает эффективность и прозрачность тестирования.
Если вы хотите поделиться своим мнением и помочь нам улучшить инструменты для тестирования, приглашаем вас поучаствовать в интервью. Для этого нужно зарегистрироваться вот тут.
Если вы нашли баг или хотите предложить новую фичю, пожалуйста, создайте задачу в YouTrack.
Комментарии (7)
DimonSmart
31.08.2021 19:46Мне очень нравится когда тест(описание) и код теста не разъезжаются по разным языкам/репозиториям/средам/программам и т.п. Бонус: Я накидал своё видение подобных тестов вот тут DimonSmart/LikeSpecFlow: Small demo, how to write tests specflow like (github.com)
Основная идея в том, чтобы разработчик, получив примерное описание теста не мучился а сразу мог его закодить. И чтобы сам код теста и был его описанием. Тогда результаты теста будут читаемы, сам тест написан на том же языке что и ведется разработка (в моём случае C#), параметризованные тесты параметризуются объектами а не строками. Тестовый фремворк - не ещё один а тот же самый что и в основном проекте. (В примере xUnit)
j8kin
01.09.2021 00:19+1Хм. Похоже вы изобрели Cucumber...
Не вижу чем ваш подход от него принципиально отличается.
lokhmakov
На главной ^^
Razmik Автор
Тест на внимательность пройден =)) Спасибо!
fiftin
Уже взяли на работу?
zloddey
Чекисты взяли в работу