Вступление

В современном мире разработки качество программного обеспечения играет далеко не второстепенную роль. И, в то время как скорость выхода релизов растет в геометрической прогрессии, тестирование выходит на новый уровень. Один из способов повысить качество выпускаемого продукта, это применение несколько иных подходов в разработке программных продуктов, а именно, различных гибких (Agile) практик и принципов. С помощью этого подхода компании стремятся сократить накладные расходы своих процессов и, в то же время, сохранить возможность быстро реагировать на изменения требований рынка, с минимальными доработками и переделками. Одно из интереснейших направлений является разработка через тестирование (TDD) и, в частности, одно из его ответвлений behavior‑driven development (BDD). BDD подход — это когда тесты пишутся на простом (не техническом) языке, который понятен и представителям бизнеса, и техническим специалистам.

Думаю, ни для кого не секрет, что хороший тестер‑автоматизатор постоянно пытается оптимизировать свою работу. И первыми помощниками в этом выступают различные фреймворки и инструменты. В сегодняшней статье мы рассмотрим основные и наиболее популярные фреймворки и инструменты для BDD тестирования. Проведя некоторый анализ, я выявил их и расположил в своем списке в порядке убывания от более популярных к менее популярным.

SpecFlow

Один из самых популярных и востребованных фреймворков является SpecFlow. Это бесплатный, опен‑сорсный проект для Microsoft.NET языков программирования. Он достаточно сильно упрощает и облегчает автоматизацию тестирования. Что в свою очередь позволяет каждому члену команды еще лучше использовать свои профессиональные качества. Еще SpecFlow имеет премиальное расширение SpecFlow+, с помощью которого можно создавать автоматически проверенные спецификации в виде живой документации, которыми потом можно делиться с остальными членами команды.

JBehave

Следующий по популярности фреймворк является JBehave. Этот фреймворк предназначен для языка программирования Java и JVM‑подобных языков, таких как Scala и Clojure и очень хорошо с ними работает. В нем можно создавать пользовательские сценарии с помощью собственного синтаксиса JBehave, а также с помощью синтаксиса Gherkin. Так же реализована интеграция с различными IDE и через плагин — с Apache Maven.

Cucumber

Еще один фреймворк с достаточно высокой популярностью это Cucumber. Данный фреймворк может работать как в связке с Java, так и с JavaScript и с Ruby. У Cucumber есть бесплатный, опен‑сорсный вариант. Существует еще платная версия Cucumber Pro, которая предлагает комфортное взаимодействие членов команды в рамках CucumberStudio и создание актуальной документации в Jira с помощью Cucumber for Jira. Вообще у Cucumber очень мощная поддержка, выражающаяся в том числе в виде Cucumber School, но это, как я понимаю, только в версии Pro.

Concordion

Concordion хорошо известен своей онлайн документацией, которая выливается в исполняемые спецификации. Упор делается на удобство и легкость чтения и визуализацию сценариев, что в свою очередь ведет к упрощению и ускорению тестирования, оставляя возможности для творчества и поиска каких‑то не стандартных ситуаций и кейсов. Concordion реализован для языков программирования Java и C#.

Jasmine

Фреймворк Jasmine создан для JavaScript. Jasmine в основном предназначен для кросс‑браузерного тестирования и для тестирования Node.js. Имеет достаточно простой и схожий с остальными фреймворками синтаксис, позволяющий легко и быстро писать тестовые сценарии. В основе Jasmine отсутствуют какие‑либо внешние зависимости, поэтому исполнение тестов проходит достаточно быстро. Запустить тесты с помощью Jasmine очень просто, достаточно заменить файлы спецификаций и сорс‑файлы на свои. К тому же в его состав уже включены примеры, которые можно адаптировать под свои нужды, ускорив тем самым процесс разработки и тестирования.

FitNesse

FitNesse это опен‑сорсный фреймворк, который предназначен для тестирования JavaScript. Его предназначение — это приемочное тестирование. Ему не нужна установка и настройка, так как он поставляется полностью готовым из коробки. Достаточно просто запустить jar файл и уже потом перенаправить ваш браузер на ту машину, где он запущен. По этой причине он достаточно легковесный. Плюс ко всему открытый исходный код упрощает жизнь не только тестерам, но и разработчикам.

Behat

Для тестирования PHP существует фреймворк Behat. Это так же бесплатный, опен‑сорсный проект. Сценарии в нем пишутся на языке Gherkin. Присутствует возможность изменять и улучшать функциональность этого фреймворка благодаря различным расширениям. В Behat достаточно неплохо реализована возможность обмена информацией между членами команды. Используется в основном для кросс‑браузерного тестирования. А отсутствие зависимости от типа операционной системы делает тестирование более обширным и функциональным.

Quantum

Quantum это кросс‑платформенный и бесплатный, опен‑сорсный фреймворк написанный на основе Java. Он может быть использован с различными языками программирования. Quantum спонсируется Perfecto при поддержке QAF. Имеет уже встроенные assertions, что облегчает написание тест‑кейсов. Благодаря исполнению тестов в облаке Perfecto процесс проходит достаточно стабильно, с гарантированным результатом, на различных устройствах, таких как стационарные компьютеры или мобильные девайсы iOS/Android.

Заключение

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

Также хочу порекомендовать бесплатный урок от моих коллег из OTUS, где будут рассмотрены основные стратегии внедрения автоматизации тестирования QA лидом. Вы сможете увидеть кейсы, как работать с автоматизацией тестирования, если вы не являетесь разработчиком, но отвечаете за нее. Разберемся с ситуацией, как развивать автоматизацию, если вам досталось legacy. Как убедить всех участников процесса развивать автоматизацию тестирования и вкладываться в нее. Рассмотрим три основные сценария: 1 — что делать если у вас вообще нет автоматизации тестирования, 2 — если она у вас есть, но в плохом состоянии, 3 — если есть и ее нужно развивать.

Комментарии (4)


  1. megamrmax
    00.00.0000 00:00
    +4

    Не BDD: пишем фреймворк, пишем тесты. Тратим силы на фреймворк и тесты только.

    BDD: появляется "гений" который заявляет что-то типа "О! а вот мы ща BDD заведем и Продакты будут писать нам сториз или тесты, онбординг будет легок и приятен и вообще я книжку прочитал/на курсы сходил - BDD это все!"
    Получаем: фреймворк с кодом, сверху слой "парсинга" этого BDD, и только потом тесты. В итоге кучу времени тратится на управление и актуализацию этих "BDD реплик", месяцев через 6 их становится чуть более чем дофига, получаются дупликаты. Ну а вишенкой на этой горке bdd-на становятся шаги, которые включают в себя куски кода или (в легкой стадии BDD болезни - json внутри шага)
    И этот лютый ад продолжается до момента, пока не появится очередной гений с "О я тут на митапе был"


    1. SergeiShaikin Автор
      00.00.0000 00:00

      Каждая компания выбирает сама то, что ей удобнее.


    1. franzose
      00.00.0000 00:00
      +1

      Сдается мне, зависит это от рук писателя. Вовремя наводить порядок надо.


    1. gigimon
      00.00.0000 00:00
      +1

      Абсолютно согласен, 6 лет использовали BDD, за это время ни один не qa не сделал ни одной правки туда, ни разу их не запустил. Зато кучу реализаций примерно одного функционала было.