Теги чаще всего используются для выбора или исключения определенных тестов из запуска. Ваша конкретная ситуация будет диктовать, какие «группы» тестов полезно запускать или не запускать для конкретного запуска теста, но некоторые распространенные примеры могут быть:
@slow - указывает на то, что запуск теста занимает много времени. Возможно, вы захотите исключить его из большинства тестовых прогонов и запускать его только при ночной сборке, чтобы разработчикам не приходилось ждать его каждый раз. @wip - указывает на то, что этот тест выполняет незавершенную функциональность, поэтому ожидается, что он потерпит неудачу, пока функция находится в разработке (и когда она будет завершена, тег @wip будет удален). Это имеет особое значение в Cucumber, так как будет возвращать ненулевой код выхода, если какие-либо @wip тесты действительно пройдут @release_x, @sprint_y, @version_z и т. Д. Многие команды помечают каждый тест информацией о том, какой релиз / спринт / версия содержит его, чтобы они могли выполнить минимальный набор тестов во время разработки. Как правило, аналогично тегу @wip, за исключением того, что они остаются прикрепленными к тесту, поэтому они всегда знают, когда была введена определенная функция. @payments, @search, @seo и т. Д. Практически любая логическая группа тестов, которая еще не выражена организацией ваших файлов объектов. Обычно используется, когда тест относится к сквозным задачам, или когда ваш проект разделен на компоненты в разных строках.
Теги также используются для запуска хуков - битов кода, которые могут выполняться до, после или «обходить» тесты с конкретными тегами. Вот некоторые примеры:
@javascript - указывает, что тесту требуется поддержка Javascript, поэтому ловушка может переключаться с драйвера только для HTTP на драйвер с поддержкой JS. Capybara делает еще один шаг вперед, автоматически переключаясь на драйвер, названный в честь тега, если он найден (так что вы можете использовать, например, драйверы @desktop, @mobile, @tablet) @logged_in - указывает, что тест должен выполняться в контексте вошедшего в систему пользователя, иногда имеет смысл выражать это с помощью тега, хотя более часто используется секция Background
Кроме того, теги могут использоваться только в информационных целях. Я видел тесты команд с тегом номер проблемы, автор, разработчик, среди прочего, многие из которых могут быть полезны (но многие из которых дублируют информацию, которую легко найти в системе контроля версий, поэтому я бы предостерег от этого) .