[Перевод] Не спешите хоронить Cucumber
Давид Дылович (Dawid Dylowicz) любит задаваться серьезными вопросами. На этот раз он любопытствует, не умирает ли Cucumber. Причина, по которой возник этот вопрос — увольнение мистера Мэтта Уинна (Mr Matt Wynne).
Cucumber — это популярный инструмент для разработки, ориентированной на BDD, который фокусируется на определении и тестировании ожидаемого поведения системы с точки зрения ее пользователей. Cucumber позволяет разработчикам писать исполняемые спецификации на простом английском языке, используя язык Gherkin, который прост для понимания как технически подкованным, так и нетехническим заинтересованным сторонам. Cucumber также поддерживает множество языков программирования, таких как Ruby, Java, Python и JavaScript, и может быть интегрирован с различными фреймворками тестирования, такими как Selenium, Capybara, Watir и Appium.
Cucumber существует с 2008 года и с тех пор завоевал большую популярность и признание в индустрии тестирования программного обеспечения. Согласно отчету State of Testing Report 2020, Cucumber занял третье место среди наиболее используемых инструментов автоматизации тестирования после Selenium и Postman. Вокруг Cucumber также выросло большое и активное сообщество пользователей и участников, которые предоставляют поддержку, обратную связь, документацию, руководства, плагины, расширения и многое другое.
Еще немного информации о сообществе:
По данным GitHub, у Cucumber более 13 000 звезд и более 2 000 форков в различных репозиториях. Это наглядно демонстрирует, что Cucumber по-прежнему является известным и уважаемым проектом в open-source сообществе, и что многие люди заинтересованы в том, чтобы внести свой вклад или учиться на его кодовой базе.
По данным Stack Overflow, по теме Cucumber оставлено уже более 25 000 вопросов и более 50 000 ответов по различным тегам. Это говорит о том, что Cucumber по-прежнему широко обсуждается и поддерживается в сообществе тестирования программного обеспечения, и что многие люди ищут или предоставляют помощь и советы по использованию и улучшению Cucumber.
Согласно данным Google Trends, Cucumber сохраняет стабильный уровень интереса с течением времени в разных регионах и на разных языках. Это показывает, что Cucumber по-прежнему остается актуальной и привлекательной темой для многих людей во всем мире, которые интересуются или увлечены BDD и тестированием программного обеспечения.
Чтобы сделать картину более полной, давайте добавим немного информации о других инструментах, которые могут быть интегрированы с Cucumber:
Serenity BDD: фреймворк, предоставляющий возможности отчетности и живой документации для BDD-проектов.
TestNG: фреймворк, предоставляющий возможности тестирования на основе аннотаций и параллельного выполнения для Java-проектов.
JUnit5: фреймворк, предоставляющий возможности расширения модели и динамического тестирования для Java-проектов.
Allure: фреймворк, поддерживающий отчетность о результатах тестирования.
Есть несколько Gherkin-проектов, которые не поддерживаются Cucumber.io (см. https://cucumber.io/docs/installation/):
Behat (для PHP)
Behave (для Python)
SpecFlow (для C#)
Cucumberish (для iOs, Swift, ObjectiveC)
Cucumber-Rust (для Rust)
Test: BDD-Cucumber (для Perl)
GoBDD (для Go)
unencumbered (для D)
Как мы видим, много людей заинтересованы в поддержке таких инструментов. Они не стали бы в это вкладываться, если бы это того не стоило.
Роль Cucumber в этом процессе. Так ли он необходим?
Во-первых, давайте посмотрим на ценность этого инструмента. Я уже писал об этом в нескольких своих постах, но давайте вернемся к этому еще раз. Cucumber — это инструмент для BDD, который представляет собой нечто более широкое, чем просто инструмент. Это своего рода философия, и ее главная ценность — это коммуникация. Cucumber организует только один аспект этой коммуникации — связи между шагами тестирования и кодом автоматизации.
Нужен ли нам этот инструмент? Ну, он полезен, но не является необходимым. Давайте представим, что нам приходится убрать Cucumber из проектов. Будет ли это катастрофой? Нет. Проблемой? Нет. Простая ли это задача? Да, и давайте взглянем на это.
Функция: F02 Поиск - Очистка критериев поиска
Шаблон сценария: Очистка критериев поиска
Дано: Пользователь находится на странице
Когда пользователь вводит значение "<Поиск>" в текстовый ввод
И пользователь выбирает значение "" в выпадающем списке
И пользователь устанавливает переключатель чувствительности регистра на ""
И пользователь очищает фильтры.
Затем пользователь должен увидеть, что критерии поиска очищены
И пользователь должен увидеть, что результаты поиска выглядят так, как в самом начале
Примеры
| Search | Column | Case |
| Alice | Name | True |
| alice | Name | False |
| alice | Name | True |
| 1 | Id | True |
| 2 | Id | True |
| 3 | Id | True |
| 4 | Id | True |
| company | Email | False |
| Athens | City | True | … в это
private static Stream clearingOfSearchingCriteriaData() {
return Stream.of(
arguments("Alice", "Name", "True"),
arguments("alice", "Name", "False"),
arguments("alice", "Name", "True"),
arguments("1", "Id", "True"),
arguments("2", "Id", "True"),
arguments("3", "Id", "True"),
arguments("4", "Id", "True"),
arguments("company", "Email", "False"),
arguments("Athens", "City", "True")
);
}
@ParameterizedTest
@MethodSource("clearingOfSearchingCriteriaData")
@Feature("F02 Searching – Clearing of searching criteria")
public void clearingOfSearchingCriteria(String search,
String column,
String caseSensitiveness) {
theUserIsOnThePage();
theUserEntersTheValueInTheTextInput(search);
theUserSelectsValueInTheDropDown(column);
theUserSetsCaseSensitivitySwitchTo(caseSensitiveness);
theUserClearsFilters();
theUserShouldSeeThatSearchCriteriaAreCleared();
theUserShouldSeeThatTheSearchResultSummaryIsAsInTheVeryBeginning();
} Рокет сайенс, да? Давайте будем честны. Здесь не нужно особенно думать; это простая ручная работа.
Придерживаемся ли мы все еще BDD? На мой взгляд, да. Единственным недостатком является то, что у нас нет хорошего инструмента, который на лету связывает все за нас и генерирует сниппеты. Однако мы все еще можем эффективно сообщать о результатах тестирования и сотрудничать в BDD-формате.
Каким будет будущее Cucumber?
Могу представить себе тестирование без Cucumber, но я верю, что этого не произойдет.
Можно рассмотреть следующие сценарии:
Сценарий 1: Проект Cucumber будет продолжать существовать и работать как проект с открытым исходным кодом, полагаясь на вклад и поддержку существующих или новых пользователей и разработчиков. Этот сценарий является оптимистичным и обнадеживающим, но он также может быть сложным и рискованным. Это потребует большой самоотдачи, координации и сотрудничества со стороны сообщества Cucumber, чтобы поддерживать проект живым и обновленным. Также этот сценарий будет зависеть от доступности и качества ресурсов, таких как документация, учебники, плагины, расширения и т.д., которые предоставляет проект Cucumber или на которые он полагается.
Сценарий 2: Проект Cucumber будет поглощен другой компанией, которая возьмет на себя его разработку и поддержку. Этот сценарий реалистичен и правдоподобен, но он также может быть неопределенным и непредсказуемым. Многое будет зависеть от намерений и возможностей нового владельца или спонсора проекта Cucumber. Такой исход может иметь полезные или вредные последствия для сообщества Cucumber и индустрии тестирования ПО в зависимости от того, как новый владелец или спонсор будет управлять проектом Cucumber или изменять его.
Сценарий 3: Проект Cucumber будет прекращен или заброшен, оставив своих пользователей и разработчиков без официальной поддержки и обновлений. Этот сценарий пессимистичен, и лично я считаю его маловероятным.
Помните ли вы историю OpenOffice? После того, как проект был поглощен Oracle, у него появились официальные специалисты по сопровождению, но сообщество предпочло создать форк. Частота релизов для LibreOffice лучше, чем в оригинальном проекте OpenOffice (см. https://www.linux-magazine.com/Online/Features/LibreOffice-vs-OpenOffice). Сейчас LibreOffice является офисным пакетом по умолчанию для большинства популярных дистрибутивов Linux. Как мы видим, поддержка проекта силами сообщества может быть очень эффективной.
Примечание: этот рассказ был первоначально написан мной, но он может содержать части, созданные с помощью ИИ. Мой оригинальный текст был частично перефразирован с помощью Chat Generative Pre-trained Transformer для улучшения языка.
Заключение
Я верю, что сообщество заинтересовано в поддержке этого проекта. Большая группа людей и проектов считают этот инструмент полезным и заинтересованы в его сохранении. Перефразируя известную цитату Марка Твена, можно сказать, что сообщения о смерти Cucumber сильно преувеличены.
Об использовании другого популярного инструмента для автоматизации тестирования — Selenium — поговорим завтра вечером на открытом уроке. На занятии мы познакомимся с основными командами взаимодействия со страницей, узнаем, как симулировать поведение пользователя, напишем первый автотест. Встреча будет особенна полезна начинающим автоматизаторам, знакомым с Java.
Записаться на открытый урок можно на странице специализации QA Automation Engineer.
