Поиск…


Вступление

Gherkin - деловой читаемый язык для автоматизации тестирования и тестовой документации. Это понимается Cucumber и вместе существует как инструмент, управляемый поведением.

Синтаксис

  • Функция: это ключевое слово означает, что следующим является базовое описание или имя проверяемой или документированной функции.
  • Предыстория: это ключевое слово означает шаги, которые будут выполняться перед каждым сценарием в этой функции.
  • Сценарий: это ключевое слово представляет собой имя или базовое описание конкретного сценария, проверяющего эту функцию.
  • Схема сценария: это ключевое слово означает, что сценарий будет выполняться N раз для каждого аргумента, указанного в примерах, явно переданных по имени столбца, заключенному в угловые скобки.
  • Примеры: это ключевое слово отмечает список статических аргументов, которые будут переданы в схему сценария.
  • Данное: данное ключевое слово представляет собой заданный шаг или предварительное условие, которое предполагается до продолжения. В параграфе «Упорядочить», «Акт», «Утверждение» задано «Упорядочить».
  • Когда: это ключевое слово представляет собой шаг when или поведение, которое должно быть указано против. В параграфе «Упорядочить», «Действие», «Утверждение» данный представляет «Закон».
  • Затем: это ключевое слово представляет собой шаг затем, или, другими словами, шаг, на котором проверяется результат поведения. В параграфе «Упорядочить», «Действие», «Утверждение» задано «Assert».
  • И: Это ключевое слово используется в сочетании с любым из указанных выше ключевых слов. Если у вас есть два заданных выражения, вместо явного вызова «Предоставлено дважды» вы можете сказать «Дано A и B».

Основы

В этом примере рассмотрим базовую структуру файла функций Cucumber в Gherkin. В базовых синтаксисах функциональные файлы используют несколько ключевых слов.

Давайте рассмотрим основные ключевые слова:

  • Функция: это ключевое слово означает, что следующим является базовое описание или имя проверяемой или документированной функции.
  • Сценарий: это ключевое слово представляет собой имя или базовое описание конкретного сценария, проверяющего эту функцию.
  • Учитывая это ключевое слово, представляет собой заданный шаг или предварительное условие, которое предполагается до продолжения. В параграфе «Упорядочить», «Акт», «Утверждение» задано «Упорядочить».
  • Когда это ключевое слово представляет собой шаг when или поведение, которое должно быть указано против. В параграфе «Упорядочить», «Действие», «Утверждение» данный представляет «Закон».
  • Затем это ключевое слово представляет собой шаг затем, или, другими словами, шаг, на котором проверяется результат поведения. В параграфе «Упорядочить», «Действие», «Утверждение» задано «Assert».
  • И это ключевое слово используется в сочетании с любым из указанных выше ключевых слов. Если у вас есть два заданных выражения, вместо явного вызова «Предоставлено дважды» вы можете сказать «Дано A и B».
  • Но это ключевое слово используется совместно с данными , When и Then для обозначения того, что что-то не должно произойти. Тогда A Но не B.

Все ключевые слова должны быть на новой строке и должны быть первым словом на новой строке, чтобы распознать парсер Gherkin. Ключевые слова Feature и Scenario должны иметь двоеточие сразу после, как показано в примере ниже. Дано, Когда, Затем, и И не требует двоеточия.

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

Feature: Product Login
    As a user, I would like to be able to use my credentials to successfully 
    login. 
    
    Rules:
    - The user must have a valid username
    - The user must have a valid password
    - The user must have an active subscription 
    - User is locked out after 3 invalid attempts
    - User will get a generic error message following 
      login attempt with invalid credentials 

    Scenario: The user successfully logs in with valid credentials 
        This scenario tests that a user is able to successfully login
        provided they enter a valid username, valid password, and 
        currently have an active subscription on their account. 

        Given the user is on the login page
        When the user signs in with valid credentials
        Then the user should be logged in

Параметрированные этапы

При написании Gherkin могут быть моменты, когда вы хотите параметризовать свои шаги для повторного использования инженером, который реализует планы тестирования. Шаги получают параметры через группы захвата регулярных выражений. ( Техническое примечание. Если у вас нет соответствующих параметров для каждой группы захвата в вашем регулярном выражении, вы можете ожидать, что будет выбрано «CucumberException: несоответствие Arity»). В приведенном ниже примере мы решили обернуть аргументы в двойные кавычки, а также как принимать целые числа в качестве аргументов.

 Feature: Product Login
    As a user, I would like to be able to use my credentials to successfully 
    login. 
    
    Rules:
    - The user must have a valid username
    - The user must have a valid password
    - The user must have an active subscription 
    - User is locked out after 3 invalid attempts
    - User will get a generic error message following 
      login attempt with invalid credentials 

    Scenario: The user successfully logs in with valid credentials 
        This scenario tests that a user is able to successfully login
        provided they enter a valid username, valid password, and 
        currently have an active subscription on their account. 

        Given the user is on the login page
        When the user signs in with "valid" credentials
        Then the user should be logged in

    Scenario: The user attempts to log in with invalid credentials 
        This scenario tests that a user is not able to log in when
        they enter invalid credentials

        Given the user is on the login page
        When the user signs in with "invalid" credentials
        Then the user should be logged in

    Scenario: The user is locked out after too many failed attempts
        This scenario validates that the user is locked out
        of their account after failing three consecutive 
        attempts to log in

        Given the user is on the login page
        When the user fails to log in 3 times
        Then the user should be locked out of their account

Особенность

Как вы могли заметить в приведенном выше примере, мы переписываем один и тот же шаг несколько раз:

Given the user is on the login page

Это может быть исключительно утомительным, особенно если у нас есть несколько заданных шагов, которые используются повторно. Gherkin предлагает решение для этого, дав нам другое ключевое слово для работы с: Background:.

Ключевое слово background служит для запуска шагов, объявленных под ним перед каждым сценарием в Feature. Не забудьте добавить фоновый шаг, если вы не уверены, что это необходимо для каждого сценария. Как и другие ключевые слова, за фоном следует описание или имя и могут содержать комментарии, перечисленные ниже. Подобно функции и сценарию, фон должен выполняться двоеточием.

Feature: Product Login
    As a user, I would like to be able to use my credentials to successfully 
    login. 
    
    Rules:
    - The user must have a valid username
    - The user must have a valid password
    - The user must have an active subscription 
    - User is locked out after 3 invalid attempts
    - User will get a generic error message following 
      login attempt with invalid credentials 

    Background: The user starts out on the login page
        Given the user is on the login page

    Scenario: The user successfully logs in with valid credentials 
        This scenario tests that a user is able to successfully login
        provided they enter a valid username, valid password, and 
        currently have an active subscription on their account. 

        When the user signs in with "valid" credentials
        Then the user should be logged in

    Scenario: The user attempts to log in with invalid credentials 
        This scenario tests that a user is not able to log in when
        they enter invalid credentials

        When the user signs in with "invalid" credentials
        Then the user should be logged in

    Scenario: The user is locked out after too many failed attempts
        This scenario validates that the user is locked out
        of their account after failing three consecutive 
        attempts to log in

        When the user fails to log in 3 times
        Then the user should be locked out of their account

Схема сценария

В некоторых случаях вы можете повторно запускать один и тот же сценарий снова и снова, заменяя аргументы. В этом случае Gherkin предоставляет несколько новых ключевых слов для размещения этой ситуации, сценарий сценария: и пример:. Ключевое слово «Сценарий» указывает Cucumber, что сценарий будет запускаться несколько раз, заменяя аргументы из списка. Ключевое слово Examples вызывается до того, как список будет явно отмечен. Аргументы для сценария Контуры должны быть обернуты в угловые скобки. В приведенном ниже примере обратите внимание, что имена аргументов, заключенные в угловые скобки, соответствуют именам столбцов, указанным в примерах. Каждый столбец разделяется вертикальными полосами с именами столбцов в первой строке.

Feature: Product Login
    As a user, I would like to be able to use my credentials to successfully 
    login. 
    
    Rules:
    - The user must have a valid username
    - The user must have a valid password
    - The user must have an active subscription 
    - User is locked out after 3 invalid attempts
    - User will get a generic error message following 
      login attempt with invalid credentials 

    Background: The user starts out on the login page
        Given the user is on the login page

    Scenario Outline: The user successfully logs in with their account
         This scenario outlines tests in which various users attempt
         to sign in successfully 

         When the user enters their <username>
         And the user enters their <password>
         Then the user should be successfully logged on

         Examples:
         | username | password |
         | frank    | 1234     |
         | jack     | 4321     |

Теги

Для целей документации вы можете фильтровать планы тестирования или сценарии по категориям. Разработчики могут захотеть запускать тесты на основе тех же самых категорий. Gherkin позволяет классифицировать функции, а также отдельные сценарии через пользователя тегов. В приведенном ниже примере обратите внимание на то, что ключевое слово Feature является тегом «@Automation». Gherkin признает это как тег пользователем символа «@». В этом примере инженер хочет дать понять, что эти тесты используются для автоматизации, где не каждый тест автоматизирован, некоторые тесты должны проводиться с помощью ручного QA.

Также обратите внимание на то, что тег @Production был добавлен в блокировку пользователя для тестирования сценариев. В этом примере это происходит потому, что этот сценарий активен только в рабочей среде приложения. Разработчики не хотят, чтобы их учетные записи в песочнице были заблокированы во время разработки. Эти теги позволяют им обеспечить, чтобы этот тест выполнялся только в рабочей среде.

Наконец, в разделе «Сценарий сценария» есть тег @Staging. Для целей этого примера это происходит потому, что используемые учетные записи являются промежуточными учетными записями и не будут работать в других средах. Подобно тегу @Production, это гарантирует, что эти тесты будут выполняться только в среде Staging.

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

@Automation
Feature: Product Login
    As a user, I would like to be able to use my credentials to successfully 
    login. 
    
    Rules:
    - The user must have a valid username
    - The user must have a valid password
    - The user must have an active subscription 
    - User is locked out after 3 invalid attempts
    - User will get a generic error message following 
      login attempt with invalid credentials 

    Background: The user starts out on the login page
        Given the user is on the login page

    Scenario: The user successfully logs in with valid credentials 
        This scenario tests that a user is able to successfully login
        provided they enter a valid username, valid password, and 
        currently have an active subscription on their account. 

        When the user signs in with "valid" credentials
        Then the user should be logged in

    Scenario: The user attempts to log in with invalid credentials 
        This scenario tests that a user is not able to log in when
        they enter invalid credentials

        When the user signs in with "invalid" credentials
        Then the user should be logged in

    @Production
    Scenario: The user is locked out after too many failed attempts
        This scenario validates that the user is locked out
        of their account after failing three consecutive 
        attempts to log in

        When the fails to log in 3 times
        Then the user should be locked out of their account

    @Staging
    Scenario Outline: The user successfully logs in with their account
         This scenario outlines tests in which various users attempt
         to sign in successfully 

         When the user enters their <username>
         And the user enters their <password>
         Then the user should be successfully logged on

         Examples:
         | username | password |
         | frank    | 1234     |
         | jack     | 4321     |

Советы по ожогу

  • Каждый сценарий проверяет одно поведение
  • Сценарии написаны декларативным образом
  • Избегайте случайных деталей внутри сценария
  • Опустить очевидное
  • Избегайте конъюнктивных шагов
  • Сократите ваши сценарии
  • Не нужно много сценариев в одной и той же функции
  • Использовать описательные имена сценариев
  • Имейте только один Когда шаг
  • Используйте «should» в шагах Then


Modified text is an extract of the original Stack Overflow Documentation
Лицензировано согласно CC BY-SA 3.0
Не связан с Stack Overflow