Нет кода? Нет проблем - написание тестов на простом английском
Как мы используем разработку, основанную на поведении, для улучшения совместной работы
Авторы NAIDELE MANJUNATH и OLIVIER DE MEULDER
Разработка, управляемая поведением, или BDD, - это подход к разработке программного обеспечения, при котором поведение функции определяется с помощью примеров в виде обычного текста. Эти примеры, известные как файлы функций, определяются до начала разработки и используются в качестве критериев приемлемости для новых функций. Файлы функций, написанные с использованием языка корнишонов, в котором используются английские слова, доступны для чтения всем, независимо от способностей к программированию. Файлы функций написаны в стиле, управляемом поведением, что означает, что они содержат подробную информацию о том, как функция должна вести себя, когда что-то происходит в данной ситуации. Это поведение - единственная информация, которая упоминается в файле функций; основные детали реализации этой функции не упоминаются.
Наша кросс-функциональная команда - отдел технологий обслуживания клиентов в The New York Times - использует файлы функций для более глубокого обсуждения нашего продукта, что помогает выработать общее понимание того, что следует разрабатывать. Когда все понимают наши пользовательские истории, мы тратим меньше времени на производственный процесс и уменьшаем количество случаев, когда мы переделываем проделанную работу. Совместное написание файлов функций способствует сотрудничеству и помогает разработчикам и специалистам по контролю качества понять бизнес-аспекты истории.
Поскольку любой член команды может читать и писать файлы функций, нам не нужно полагаться на тестировщиков или инженеров по обеспечению качества при написании тестов.
Наш процесс
В начале каждого спринта наш менеджер по продукту пишет пользовательские истории для каждой функции, следуя принципам Agile. Вот простой пример пользовательской истории, которую мы могли бы включить в один из наших спринтов:
Как представитель службы поддержки клиентов, я хочу обновить данные кредитной карты клиента, чтобы средства с новой кредитной карты были списаны в течение следующего платежного цикла.
Когда пользовательские истории написаны, наш менеджер по продукту и наши разработчики вместе переводят пользовательские истории в файлы функций. Файлы функций служат схемой для автоматизированных сквозных тестов, за написание которых несут ответственность разработчики.
Следуя нашему примеру пользовательской истории выше, файл функций может выглядеть следующим образом:
Автоматические тесты написаны на Javascript. Каждая строка Given, When и Then в файле функций соответствует простой функции Javascript, а строка Then будет содержать тестовое утверждение. Наша команда использует библиотеку утверждений Mocha, webdriver.IO в качестве средства запуска тестов и фреймворк Cucumber для интерпретации функции тестирования, но можно использовать любую. Разработчик, работающий над автоматизированным сквозным тестом, может запустить тест локально на своей машине.
И здесь происходит волшебство.
Средство выполнения тестов анализирует файл функций, определяет, какие функции JavaScript нужно запустить, и сообщает об этом.
После успешного прохождения всех сквозных тестов остается еще один шаг. Платформа тестирования BDD интегрирована в наш конвейер непрерывной интеграции (CI). Это позволяет каждому убедиться, что тесты выполняются в промежуточной среде.
Отчет об испытании может выглядеть так:
Как видите, отчет легко читать, даже если у вас нет технической подготовки.
Итак, в чем ценность BDD? Наша команда увидела четыре ощутимых преимущества:
Расширение сотрудничества. Менеджер по продукту участвует в разработке тестов, что означает, что они работают с разработчиками (и QA, если применимо), чтобы четко сформулировать бизнес-правила. Каждый член команды хорошо разбирается в новых функциях продукта, и каждому члену ясно видно, как продвигается работа над проектом.
Живая документация. Поскольку файлы функций служат для проверки перед выпуском функций в рабочую среду, их необходимо поддерживать в актуальном состоянии. Любые изменения продукта или функций означают, что файлы необходимо обновить, чтобы избежать сбоев, вызванных определениями функций. В то время как документация часто остается в стороне при разработке программного обеспечения, BDD делает ее неотъемлемой частью процесса разработки.
Быстрое наращивание. Код не всем понятен. Кроме того, из него плохая документация. Работа с членами команды, которые не понимают код, обычно означает, что команда должна создать отдельный документ, например электронную таблицу, для описания того, что покрывается тестовым кодом. BDD помогает решить эту проблему с файлами функций. Новички в команде могут читать файлы функций и быстро понимать, что делает функция. Это лучше, чем копаться в тоннах документации.
Читаемые отчеты. Обычно результаты тестирования не представлены в удобном для пользователя формате - в журнале отчета может быть написано что-то загадочное, например: «Ожидаемое ложное значение равно истине». Хотя это может быть легко читать, контекст или значение не ясны для читателя: что ожидалось, чтобы быть правдой, а теперь ложью? С результатами BDD каждый результат подпадает под соответствующий сценарий в файле функций BDD, что обеспечивает лучшую читаемость.
Наша команда начала использовать BDD несколько месяцев назад. Сначала это было немного страшно и подавляюще, потому что всем нужно было изучить новый технический навык и работать вместе по-новому. Со временем команда освоила тестирование BDD и обнаружила, что тесная совместная работа - это очень естественный процесс. Когда команда совместно работает над файлами функций, мы более согласованы в цикле разработки, и продукт становится лучше.
Найдел Манджунатх - инженер-программист из группы автоматизации тестирования New York Times.
Оливье Де Мелдер (Olivier De Meulder) - технический менеджер в The New York Times Subscription Platforms Group.
