что такое bdd в тестировании
BDD — рабочий метод или TDD в модной обертке?
Два подхода к разработке через тестирование вызывают особенно много споров — из-за некоторого методологического сходства TDD (Test Driven Development) и BDD (Behaviour Driven Development) часто путают даже профессионалы. Старшие инженеры по автоматизации тестирования «Альфа-Лаборатории» Юлия Ковалева и Анна Чернышева рассказывают базовые вещи о сходстве и различиях двух популярных методик и то, какой подход у них используется в самой компании.
Юлия Ковалева, старший Java-разработчик автотестов в «Альфа-Лаборатории»
Посвятила тестированию более 4 лет, сейчас разрабатывает библиотеку шагов для масштабирования автоматизации тестирования с использованием Cucumber и Selenide.
Анна Чернышева, старший Java-разработчик автотестов в «Альфа-Лаборатории»
Работала в крупных e-commerce проектах, участвует в создании и поддержке нескольких BDD-фреймворков, а также занимается внедрением инженерных и DevOps-практик.
— В чем заключается основное различие методик TDD и BDD?
Анна Чернышева: Понимание методик TDD и BDD отличается в разных компаниях, мы расскажем о том, как все устроено в «Альфа-Лаборатории». Концепции обоих подходов похожи, сначала идут тесты и только потом начинается разработка, но предназначение у них совершенно разное. TDD — это больше о программировании и тестировании на уровне технической реализации продукта, когда тесты создают сами разработчики. BDD предполагает описание тестировщиком или аналитиком пользовательских сценариев на естественном языке — если можно так выразиться, на языке бизнеса.
— BDD — просто модное слово или принципиально новый подход к разработке через тестирование? От TDD его отличает только использование естественных языков для описания тестов?
Юлия Ковалева: BDD и в самом деле модное слово, но далеко не все умеют его правильно «готовить». В «Альфа-Лаборатории» нам пришлось комплексно подойти к решению задач и полностью изменить многие аспекты функционирования всей команды, что позволило существенно удешевить процесс тестирования. Нанять умеющего описывать тестовые сценарии на русском языке человека намного проще, чем найти специалиста, способного реализовать эти тесты, например, на Java.
BDD подход совместно с инженерными практиками позволил нам отказаться от legacy-документации, содержащей неактуальную информацию, и получать новую документацию налету, хранить ее вместе с проектом, что позволило приблизить аналитиков и тестировщиков к коду.
— В разработку сценариев BDD вовлечены не только тестировщики, необходимость в автоматизаторах сохраняется?
Юлия Ковалева: Разумеется, оставить в команде только тестировщиков без автоматизаторов — достаточно недальновидно. Потребуется некий инструментарий и владеющий им человек, чтобы реализовать ту техническую составляющую, которую тестировщик самостоятельно сделать не сможет.
Анна Чернышева: Потребность команды в количестве экспертов по автоматизации тестирования уменьшается, поскольку есть фреймворки, которыми могут пользоваться тестировщики. Автоматизатор добавляет новую функциональность в тестовый фреймворк, и она сразу становится доступна всем командам.
— Помимо традиционных для TDD unit-тестов при использовании BDD-подхода проводятся также behavior-тесты. На этом различия процессов тестирования заканчиваются или дело обстоит сложнее?
Анна Чернышева: Все гораздо сложнее, поскольку BDD — скорее процесс, целью которого является удешевление реализации новых фич. Еще на старте разработки мы получаем важные артефакты. Например, понятную для поддержки документацию. Эта документация дает возможность всем заинтересованным лицам сформировать свое представление о продукте и сценариях пользовательского поведения, которые должны быть реализованы в ходе итераций разработки. С BDD-подходом мы также снижаем порог входа в проект новых участников.
— Многие считают, что BDD можно рассматривать как переход от основанной на unit-тестах разработки к разработке, основанной на интеграционном тестировании. А как ситуация обстоит на самом деле?
Юлия Ковалева: Мы провели такой эксперимент. Попытка использовать BDD-инструменты для написания unit-тестов успехом не увенчалась, через какое-то время разработчик отказался писать поведенческие тесты. Когда мы говорим про автоматизацию, BDD идеально вливается в эту историю, но применять такой подход к модульному тестированию не стоило, пользы нам это не принесло. При интеграционном тестировании польза от BDD будет значительной — здесь мы смотрим на весь продукт в целом.
— В каких случаях для тестирования применяется BDD подход и чем он лучше более традиционного TDD?
Анна Чернышева: BDD в основном используется для проверки взаимодействия разных компонентов системы, это, как уже было сказано, уровень интеграционного тестирования — оно поведенческое и проверяет различные бизнес-кейсы. TDD используется для разработки через модульное тестирование непосредственно программистами, которые пишут код через этот подход. В общем, если по-простому, TDD проверяет исключительно модули, а BDD — пользовательские сценарии.
— Зачем потребовались новые BDD-фреймворки, не проще оформить BDD в набор рекомендаций по написанию TDD и использовать существующие?
Юлия Ковалева: BDD появился, чтобы сделать команду разработки ближе к бизнесу, организовать диалог между бизнесом, разработчиками и тестировщиками. При TDD-подходе нужно писать тесты на формальных языках программирования. Тесты и код лежат в одном месте, их достаточно сложно поддерживать, а уж тестировщик или бизнес-аналитик едва ли полезет смотреть, что мы там написали. Два наиболее популярных BDD фреймворка — JBehave и Cucumber. Как их правильно применять, мы расскажем на ближайшей конференции Гейзенбаг 2017 Piter.
Анна Чернышева: Эта путаница между TDD и BDD пошла от общей для разных подходов идеи: сначала пишутся тесты, а потом идет разработка. При всех сходствах они предназначены для разных целей и требуют применения различных инструментов.
— То есть BDD нельзя считать расширением TDD?
Анна Чернышева: Да, мы считаем именно так. Вместо тестовой модели у нас есть пользовательские сценарии, которые мы автоматизируем в одном спринте с разработкой. Более того, в «Альфа-Лаборатории» BDD-подход органично внедрен и в инженерные практики.
— QA считают женской профессией. Как вы полагаете, с чем это связано и насколько соответствует действительности? Есть ли вообще в IT понятие женской и мужской профессии?
Анна Чернышева: Сейчас от этого стараются уйти, но женское мышление более абстрактно, а мужчинам важны конкретные детали — это, конечно, все индивидуально, но если брать «Альфа-Лабораторию», то девушек-тестировщиков в процентном соотношении несколько больше. Может, тестирование требует творческого подхода, а девушки — более творческие натуры?
Юлия Ковалева: Можно провести эксперимент и подсчитать, сколько девушек и мужчин придут на Гейзенбаг.
На Гейзенбаг 2017 Юлия Ковалева и Анна Чернышева сравнят Cucumber и JBehave. У какого BDD-фреймворка больше возможностей? Как их правильно «готовить» и с какими трудностями придется столкнуться во время тестирования — состязание ведущих разработчиков автотестов «Альфа-Лаборатории» пройдет в лучших традициях Mortal Kombat.
Полная программа конференции доступна на сайте.
Тестирование с использованием BDD
Введение
TDD и BDD
Я не буду тут ссылаться на статьи и презентации корифеев IT индустрии. Мне запомнилась одна фраза из Twitter по поводу TDD которая засела в моем сознании, и которая на мой взгляд четко и коротко характеризует TDD подход. К сожалению дословно я её привести не могу, но смысл в ней следующий: «если вы следуете TDD, то можете быть 100% уверены, что каждая строчка кода была написана благодаря упавшему(ым) тесту(ам)». Я видел и слышал много дебатов по поводу достоинств и недостатков TDD и BDD, но а) тесты писать надо б) если код был написан благодаря упавшему тесту, то этому коду можно доверять, и с легкостью его изменять (рефакторить) не боясь испортить поведение системы.
Теперь про BDD. Появилось это явление позже и как утверждает Фаулер в статье «Mocks Aren’t Stubs» благодаря так называемым мокистам. С другой стороны этот подход активно продвигают ребята из Agaile тусовки, сводя к минимуму расстояние между разработчиками, пользователями и аналитиками систем. Достигается это путем получения Executable Scenarios, иными словами, сценарии которые описывают пользователи переводятся в исполняемый тест. BDD frameworks с этим удачно справляются.
Теперь перейдем к сравнению.
Все примеры описывают один и тот же сценарий. Я опущу описание проблемы решение, которой необходимо покрыть тестами, потому как сами сценарии должны ясно описать её.
Автор статьи приводит реализации BDD в порядке возрастания симпатии к ним.
Easyb
Данный framework написан на Groovy. Как и все BDD реализации поддерживает нотацию Given-When-Then. Легко интегрируется в Continuous Integration (CI).
Вот пример сценария:
description «This story is about sqrt optimisation algorithm»
narrative «this shows sqrt optimisation», <
as a «java developer»
i want «to know how sqrt optimisation works»
so that «that I can pass google interview»
>
before «init input and expected result», <
>
scenario «find summ within two indexes #leftIndex and #rightIndex of the array #input», <
given «An Sqrt algorithm implementation», <
alg = new SqrtDecompositionSum(input.toArray(new int[0]))
>
when «calc sum between two indexes», <
actualSum = alg.calcSummBetween(leftIndex, rightIndex)
>
then «summ should be equal expected #expectedSumm», <
actualSum.shouldBe expectedSumm
>
>
Вот как выглядит результат теста: 
Тут «вылазит» первый недостаток easyb. Дело в том, что непонятно откуда взялось 2 сценария, в то время как описан 1. Если вглядеться в секцию where сценария, то можно увидеть, что подготавливается 2 набора входных и ожидаемых значений. К сожалению конструкция where не документирована даже на сайте проекта, по крайней мере я её там не нашел.
Ниже приведен пример упавшего теста-сценария 
Spock
Spock, на мой взгляд, ближе к разработчику нежели к аналитику или QA инженеру, однако все равно легко читаем.
Cucumber
С Cucumber я познакомился совсем недавно, и чем больше я с ним экспериментировал, тем больше он мне нравился. В отличие от первых двух, Cucumber выходец из Ruby. Существует его реализация для Java и С#.
Сценарии на cucumber состоят из двух файлов: собственно сценарий, и его реализация на Java, C#, Ruby. Это позволяет отделить сценарий от реализации, что делает сценарии абсолютно обычным повествованием на английском языке, приведем пример
Feature: Sqrt Sums Algorithm Feature
In order to ensure that my algorithm works
As a Developer
I want to run a quick Cuke4Duke test
Кстати, сценарии в cucumber называют features.
А вот реализация
public class SqrtsumsalgFeature <
private Algorithm alg;
private int result;
@Given («^The input array ([\\d\\s\\-\\,]*)$»)
public void theInputArray(String input) <
String[] split = input.split(«,»);
int[] arrayInput = new int[split.length];
for (int i = 0; i
Тут нужно соблюдать Naming Conventions как в именах файлов сценария и реализации, так и в именах методов реализации и шагов сценария. Иными словами они должны соответствовать. Соответствие достигается путем использования аннотаций Given, @When, Then и строк регулярных выражений в качестве аргументов к аннотациям.
Используя группы регулярных выражений можно выделять аргументы методов реализации.
Ниже приведен пример прошедшего теста на cucumber
А вот пример упавшего feature
Мне по-душе разделение сценария от его реализации. Кого то может смутить использование регулярных выражений чтобы «увязать» реализацию со сценарием, однако они скрыты от пишущего сценарий, и большинство разработчиков знакомы с ними, так что этот факт я бы не стал относить к недостаткам. За информацией о cuke4duke — реализации для Java прошу зайти сюда.
BDD-тестирование чат-бота
Многие знакомы с методологией Test-Driven Development и, в частности, Behavior-Driven Development. Этот подход к разработке и обеспечению качества ПО набрал большую популярность, поскольку позволяет выстроить четко установленное соответствие между бизнес-требованиями и технической реализацией продукта.
На Russian Python Week 2020 Владислав Мухаматнуров, Senior QA automation на примере проекта голосового ассистента в Tinkoff, разобрал задачи, которые решает BDD. В своем докладе Влад разобрал, что такое BDD и Gherkin, откуда возникает потребность в поведенческом тестировании на проекте и как выглядит имплементация предметно-ориентированного языка для тестирования, базирующейся на диалогах системы. А под катом мы предлагаем вам прочитать расшифровку доклада.
Проект: Голосовой Ассистент «Олег»
Это тот самый голосовой помощник, который помогает людям в чатах мобильных приложений или когда они звонят в банк. Голосовой ассистент Олег от Tinkoff Mobile берет трубку и общается с клиентами.
Давайте подробнее поговорим об этом проекте:
В основе системы лежит:
Классификация и распознавание намерения пользователя;
Генерация действий на входное воздействие;
Сообщения в диалогах классифицируются на основе направленного ациклического графа.
Направленный ациклический граф
Это граф, который имеет начальный и конечный узлы, и из первого во второй можно добраться различными путями, в том числе параллельными. Но при этом нельзя выйти из начального узла и вернуться обратно в начальный узел.
Основные сервисы:
диалоговая платформа, которая осуществляет маршрутизацию сообщений клиента по нужным каналам обработки;
классификаторы, позволяющие выделять полезную нагрузку из сообщений пользователя и правильно понимать, как ее нужно обработать;
CRM-система, которая содержит процедуры работы с клиентами;
Тестирование на проекте
Однажды мы задались вопросом, как организовать тестирование на таком сложном проекте? Более того, у нас появились другие вопросы:
что у нас является тест-кейсом?
каким может быть входное воздействие на нашу систему?
каким может быть результат обработки сообщений?
как все это автоматизировать?
Мы начали думать и формулировать, как могут быть выражены бизнес-кейсы использования нашей системы. Для начала нужно было посмотреть на диалоги системы и пользователя:
Есть четко регламентированные воздействия на систему со стороны пользователя, а в ответ на эти воздействия система что-то генерирует. Попытаемся классифицировать эти ответы.
Посмотрим на взаимодействие в чате.
надиктовать текст голосом;
нажать на подсказку;
нажать на кнопку виджета;
ответить текстом и голосом;
То есть бот делает то же самое, что пользователь, но в обратную сторону.
Описание бизнес-кейса
На основе этого сформировалось понимание, как может выглядеть бизнес-кейс на бумаге. Например:
User stories
В примере приведена пользовательская история. Это способ описания требований к разрабатываемой системе, сформулированных при помощи предметно-ориентированного языка.
Особенности user stories:
быстрый способ документировать требования бизнеса к реализации продукта;
минимизация обширных формализованных технических и бизнес спецификаций;
низкая цена поддержки.
На основе этого мы сформулировали требования к нашему процессу обеспечения качества и, в принципе, к улучшению процесса разработки на проекте.
Так, мы хотели связать постановку технических и бизнес-задач на основе историй использования системы, получить фундамент для тест-кейсов на основе бизнес-кейсов, автоматизировать регресс системы на основе пользовательских историй. Кроме того, нам было важно пополнить процесс разработки возможностью описать поведение системы и при помощи этих историй добиваться ее работоспособности согласно сценариям.
Я расскажу о чертах BDD или «разработки на основе поведения».
BDD — это ответвление методологии разработки через тестирование. Суть BDD заключается в том, что у нас есть бизнес-требования к продукту, которые мы описываем на предметно-ориентированном языке и получаем сценарий использования системы. Далее реализуем техническую часть системы и в конечном итоге создаем крутой конкурентноспособный продукт.
Классический цикл Behaviour-Driven Development состоит из 5 шагов:
Описываем поведение системы.
Определяем технические требования к системе.
Запускаем тесты или руками проверяем сценарии поведения. А они, естественно, падают, потому что система еще не готова или не реализована.
Дорабатываем нашу систему, то есть создаем, обновляем, дополняем, изменяем.
Добиваемся того, чтобы система проходила наши сценарии использования.
В основе BDD лежат спецификации поведения. Это документы, которые имеют следующую структуру:
заголовок — описание бизнес-цели;
описание — субъект, состав истории, ценность для бизнеса;
сценарии — ситуация поведения субъекта.
Gherkin и детали имплементации BDD
Gherkin — это предметно-ориентированный язык (по сути DSL), который позволяет описать поведение системы при помощи специальных ключевых слов, заранее зафиксированных.
Пример сценария, написанного на Gherkin:
В Gherkin употребляются ключевые слова. Их можно объединить по 4 основным группам:
Scenario Outline / Структура сценария
Язык Gherkin: ключевые слова
Пройдемся по этим ключевым словам.Ключевое слово: Функция.
Это название спецификации, отражающее определенную бизнес-функцию. Первая строчка в документе, описывающем ее, должна начинаться с ключевого слова «Функция:».
Ключевое слово: Сценарий.
Рядом с ключевым словом размещается краткое описание сценария.
Ключевое слово: Структура сценария.
Структура сценария позволяет избежать повторения конструкций. Когда вы пишете много похожих друг на друга сценариев, их можно шаблонизировать. Для этого и употребляется структура сценария.
Ключевое слово: Примеры.
Это таблицы с данными для параметризации структуры сценария. Они могут содержать много переменных, быть заданы горизонтально и вертикально, как представлено в примере.
Ключевое слово: Предыстория.
Предыстории добавляют определенный контекст ко всем Сценариям в пределах Функции. Фактически, Предыстория — это сценарий без имени, состоящий из конечного множества шагов, которые, как правило, специфицируют систему и пользователя перед каждым Сценарием.
Ключевое слово: Дано.
Назначение шагов Дано состоит в приведении системы и ее пользователя в определенное состояние. Их можно рассматривать как предусловия сценария.
Ключевое слово: Когда.
Основная задача этого ключевого слова состоит в описании ключевого воздействия, совершаемого пользователем на нашу систему.
Ключевое слово: Тогда.
Оно необходимо для наблюдения за результатом выполнения действий. По сути, для проверки вывода системы (отчеты, интерфейс, сообщения). Наблюдения должны быть связаны с описанием Функции и Сценария.
Ключевые слова: И, Но.
Это предлоги. Они необходимы, когда есть несколько последовательных шагов Дано, Когда или Тогда. В данном случае предлог И — это смысловой аналог конъюнкции, а предлог Но — смысловой аналог инверсии.
Пример диалога системы с пользователем
Рассмотрим простейший пример, где пользователь пишет «Привет!», а бот отвечает ему текстом и показывает подсказки:
Рассмотрим, как это можно зафиксировать при помощи наших сценариев и спецификаций поведения.
Пример использования Gherkin
Здесь есть конкретная Функция: Бот умеет приветствовать пользователя. Кроме того, мы видим предысторию, о том, что это за клиент, в какой ОС он сидит и какую версию приложения использует. Ведь в зависимости от разных версий приложения могут быть показаны разные виджеты.И у нас есть сам сценарий, согласно которому в ответ на то, что пользователь пишет: «Привет!», бот отвечает фиксированным текстом и дает фиксированные подсказки.
Пример отчета по сценарию поведения
Это автоматически сгенерированный отчет при помощи нашего внутреннего инструмента автоматизации, который отражает сценарий поведения с результатом Passed:
Пример посложнее: «Поездка за границу»
Тут пользователю необходимо написать о своем намерении уехать за границу. Бот это поймет, предложит добавить поездку, и начнется выбор страны, даты отъезда и т.д. А дальше мы ждем, что пользователь подтвердит факт, что поездка планируется.
Так может выглядеть этот бизнес-кейс при помощи нашего предметно-ориентированного языка:
То, что вы видите в приложении и пишите системе, описывается в сценариях поведения. У нас появляется прямое соответствие бизнес-кейсов и тест-кейсов, то есть они, по сути, идентичны.
А при помощи инструмента автоматизации можно собирать входные воздействия и добавлять регресс, автоматизировать, делать аналитику на основе получаемых данных.
Пример отчета по сценарию поведения
Интересно рассмотреть, как реализуется Gherkin «под капотом».
У нас есть инструмент автоматизации. К нему прикручивается плагин имплементации конкретно для нашего языка программирования. Далее, на основе этой конструкции, реализуется каркас предметно-ориентированного языка, и затем можно писать спецификации поведения.
Задачи, решаемые BDD
Я выделил три важные задачи, которые решает разработка на основе поведения:
объединение бизнеса и разработки;
установление единого восприятия бизнес-кейсов;
удешевление поддержки тест-кейсов.
Рассмотрим классическую ситуацию.
У нас есть продукт, а у него продакт-менеджер. Он хочет очередной бизнес-эпик, описывает его в виде бизнес-требований и передает в команду.
У команды есть технический аналитик, который на основе бизнес-требований формирует технический эпик и техническую спецификацию по данной фиче. На основе технической спецификации команда разработки реализует функциональность. Согласно задачам, эта функциональность поступает в отдел тестирования. И QA при помощи тест-кейсов тестирует фичу, находит баги или подтверждает работоспособность нашей системы.
В конечном итоге у нас сформирована спецификация по тестированию данной фичи.
Итак, у нас есть три основные документа:
Бизнес-требования к продукту.
Техническая спецификация продукта.
Спецификация по тестированию продукта.
И вот он — классический случай, где каждый из документов является новым отображением на основе предыдущего документа. Проблема в том, что у нас нет единого понимания, что такое сценарий использования приложения, и часто размыты понятия поведения системы и пользователя в этих документах. Как следствие, бизнес-кейсы сильно отличаются от тест-кейсов. Разница в формате реализации документов приводит к проблемам в восприятии информации участниками процесса.
Например, продакт-менеджер приходит и задает важный и правильный вопрос про фичу у продукта.
Чтобы ответить на него, QA переводит с бизнес-языка на технический: что за пользователь, как реализуются обработка конкретной группы и выполнение условия C в системе?
А потом смотрит, есть ли у нас кейсы на проверку комбинации из заданных технических особенностей при указанном условии. Если кейсы есть, QA сразу дает ответ. А если нет, проверяет руками.
На картинке QA дает ответ на вопрос менеджера продукта, но как будто бы на своем языке. И он тоже прав. Он дал абсолютно корректный, правильный ответ. Но кажется, что этот ответ не совсем коррелирует с заданным вопросом.
BDD — это про объединение бизнеса и разработки. Постановка задач BDD от бизнеса выполняется в виде спецификаций поведения. Такие спецификации уже используются в качестве основы для технических требований, а также являются фундаментом для тест-кейсов.
Единое восприятие продукта
Мы начинаем воспринимать продукт одинаково. Когда менеджер в следующий раз задаст свой правильный и важный вопрос, QA ответит на его языке:
Он ответит так, потому что у него есть тот самый бизнес-кейс, который уже написан на Gherkin. В нем описывается функция и конкретный сценарий поведения.
У нас появляется единое восприятие бизнес-кейсов. Спецификации поведения (на основе утвержденного шаблона) понятны всем: продуктологам, аналитикам, разработчикам и тестировщикам.
Такие сценарии легко реализуемы. А если их автоматизировать, вы получите эффективный инструмент для сбора аналитики и формирования отчетов. Кроме того, эти сценарии позволят вам итеративно улучшать продукт.
Всё это можно делать непрерывно, ежедневно улучшая продукт. Также BDD позволяет удешевить поддержку тест-кейсов.
Спецификации поведения сами по себе реализуются на основе набора простых конструкций имплементированного предметно-ориентированного языка. По сути такие сценарии почти не зависят от программной реализации вашего инструмента автоматизации «под капотом».
То есть можно взять любой инструмент автоматизации, но при этом использовать один предметно-ориентированный язык, те же самые спецификации поведения, и все должно быть идентично. Не нужно переписывать тест-кейсы, если вы меняете фундамент инструмента автоматизации.
Давайте сравним тест-кейсы автоматизации: слева — уже привычный тест на Gherkin, справа — кейс на фреймворке Tavern.
Справа более технический тест-кейс, а слева, по сути, просто описание бизнес-функции. Но, как правило, всем приятнее видеть именно то, как работает система в тест-кейсах, и какие она генерирует ответы на запросы.
Преимущества интеграции BDD
На собственном опыте мы ощутили преимущества интеграции BDD:
Идеально тестировать диалоги чат-бота и говорящего робота.
Понятная спецификация системы и пользователя, например:
Версии приложения, ОС, часовой пояc.
Тип клиента, продукта, номер телефона.
На основе ограниченного набора шагов мы сделали маппинг. Используем ключевые слова:
Дано — для спецификации пользователя и системы, как это канонически предусмотрено.
Когда — для описания действий пользователя.
Тогда — для описания реакции системы.
Проблемы, не решаемые BDD
Процесс разработки: если он плохо поставлен, интеграция BDD не сделает его быстрее и качественнее.
Регрессионное тестирование: при отсутствии (или серьезной нестабильности) QA-контура или стейджинга не будет возможности обеспечить регресс на основе созданных сценариев поведения, в том числе, автоматизированный.
Релизный процесс: при отсутствии поставленных в командах проекта процессов по контролю качества и релизам, интеграция BDD не позволит гарантировать работоспособность согласно спецификациям поведения.
Если вы делаете BDD, нужно контролировать работоспособность системы до того, как все это выкатится в продакшен. Только тогда BDD принесет классные результаты.
Видео доклада можно увидеть тут.
Профессиональная конференция для Python-разработчиков пройдет 27 и 28 сентября в Москве. Но посмотреть расписание и выбрать самые интересные доклады можно уже сегодня.
Не забудьте купить билеты. Встречаемся в офлайне в конце сентября!