Почему я больше не использую Cucumber при автоматизации тестирования
Robin XUANОдин из важных принципов для инженера - признать свою вину. Должен признать, что использую Cucumber неправильно :)
Если вы прочитаете другую мою статью, то обнаружите, что я всегда пытаюсь найти разные способы для быстрого тестирования: короткий agile-процесс с осмысленной методологией затрат времени, чтобы помочь команде создать качественный продукт.
Определение BDD из википедии.
BDD (сокр. от англ. Behavior-driven development, дословно «разработка через поведение») — это методология разработки программного обеспечения, являющаяся ответвлением от методологии разработки через тестирование (TDD). Основной идеей данной методологии является совмещение в процессе разработки чисто технических интересов и интересов бизнеса, позволяя тем самым управляющему персоналу и программистам говорить на одном языке.
Что такое Cucumber
Cucumber - это инструмент для поддержки формата BDD и способ написания тест-кейса с помощью операторов Given-When-Then.
В идеале тест-кейсы разрабатываются среди разработчиков, QA и бизнес-участников и других нетехнических людей в формате "Given-When-Then" и выполняются по завершении разработки, чтобы обеспечить соответствие кода бизнес-требованиям.
Все это уже сказано, но заметили ли вы, что в этом процессе происходит трансформация тест-кейса?
Разработанный тест-кейс (слева) НЕ МОЖЕТ использоваться в коде Cucumber (справа), он был преобразован в своего рода технический код в формате Given-When-Then. Вы, может быть, будете категорически против меня, вы подумаете, почему мы не соблюдаем один и тот же код? Посмотрите на сценарий ниже.
Feature: Search Scenario: I can search successfully Given I am in home page When I search "abc" Then I see "abc" is exist Scenario: I can search by auto suggestion Given I am in home page When I search "abc" by auto suggestion Then I see "abc" is exist Scenario: I can search by auto by press enter Given I am in home page When I search "abc" by press enter Then I see "abc" is exist ----------------------------- Scenario: I can search successfully Given I am in home page When I type "abc" in search filed And I click search button Then I see "abc" is exist Scenario: I can search by auto suggestion Given I am in home page When I type "abc" in search filed And I select search suggestion Then I see "abc" is exist Scenario: I can search by press enter Given I am in home page When I type "abc" in search filed And I press enter Then I see "abc" is exist
Есть 3 способа поиска, как описано выше. Сравнивая первые 3 сценария и последние 3 сценария, разница заключается в том, что первый написан на языке бизнеса, а второй - на языке действий.
У вас есть 2 варианта:
- реализовать все бизнес-шаги как шаг “I search” в первых 3 сценариях.
- реализовать все на языке действий как в последних 3 сценариях.
Используя 1-е решение, через полгода у вас будет взрывной рост шагов, и тогда станет очень дорого:
- поддерживать все шаги и выяснять повторяющиеся шаги
- обеспечивать, чтобы QA, разработчики, бизнес и нетехнические участники всегда повторно использовали существующие шаги
- обучать новых членов команды
Используя 2-е решение, тогда становится очень дорого:
- обеспечивать QA, разработчикам, бизнес-и нетехническим участникам информацией о всех именах элементов, используемых в click/press/etc, и их изменениях в будущем
- поддерживать этот формат теста как критерий приемки в бизнесе, который трудно читать и понимать
Если вы не хотите использовать ни 1-е решение, ни 2-е решение. Тогда мы должны преобразовать Business BDD в Technical BDD.
Таким образом, люди, которые разработали тест-кейс, будут писать на бизнес-языке BDD, люди, которые пишут автоматизированный тест, преобразуют его в правильные шаги на уровне действий и создадут файлы BDD .feature.
Давайте посмотрим, где мы тратим наше время:
- Вам необходимо поддерживать дополнительный слой в коде - шаги.
- Вам нужно преобразовать Business BDD и написать свой собственный Technical BDD, но никто его не читает и не использует.
- Вам необходимо связать свои собственные тесты Technical BDD с хорошо написанными тест-кейсами Business BDD в системе управления тест-кейсами.
Делать все это только для того, чтобы вы выглядели более занятыми? Люди все еще могут сказать:
Мы используем формат BDD как мост между бизнес и техническими специалистами.
Если вы один из этих людей, то стоит продолжить читать статью.
Я, может быть, не только я, обнаружил, что мы действительно перепутали (или неправильно поняли с самого начала) две вещи:
- дизайн тест-кейса в формате BDD
- реализация автотеста в формате BDD
Дизайн тест-кейса в формате BDD не означает, что наш код должен на 100% соответствовать Given-When-Then, и использование формата Given-When-Then не означает, что у вас BDD.
Посмотрите на следующий код для того же тест-кейса, что и выше:
describe("Search", () => { it("get result by click search button", () => { pageHome().visit() .type("[data-testid='search-input']", "abc") .click("[data-testid='search-btn']") searchResult.should('be.visible') }); it("get result by auto suggestion", () => { pageHome().visit() .type("[data-testid='search-input']", "abc") .click("[data-testid='search-suggestion-item']") searchResult.should('be.visible') }); });
Что вы получаете:
- Не нужно поддерживать слой шагов, меньше кода, а также быстрое тестирование и быстрая обратная связь
- QA и Dev могут внести свой вклад в этот тест
- QA и Dev могут поддерживать тест при изменении локатора
- Нет риска, когда присоединится новый член команды
Вся команда заботится о качестве - это уже не просто слова.
В чем моя идея:
- Создавайте тест-кейсы на языке BDD, пишите на бизнес-языке в системе управления тест-кейсами (например, TestRail, JIRA Test case и т. д.). Таким образом, вы по-прежнему пользуетесь методологией BDD и поддерживаете связь между техническим и бизнесом отделами.
- Реализуйте автотесты в стиле модульного тестирования на основе тест-кейсов BDD, никаких .feature или Given-When-Then.
- BDD не только про «Given-When-Then» в вашей сторе! BDD - это процесс поощрения сотрудничества между разработчиками, QA и нетехническими или бизнес-участниками проекта, а также предоставление стандартного способа описания бизнес-требований. BDD != Напишите тест-кейс в Cucumber.
Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.