Ваш босс не оценит TDD: попробуйте этот пример разработки, основанной на поведении

Тестирование. Часто его оставляют на последнюю минуту, а затем обрезают, потому что у вас нет времени, слишком много бюджета или что-то еще.

Руководство недоумевает, почему разработчики не могут просто «сделать все правильно с первого раза», а разработчики (особенно в больших системах) могут быть застигнуты врасплох, когда разные заинтересованные стороны описывают разные части системы, как, например, в истории о слепых, описывающих слон.

Однако неизбежно, что первым шагом в каждом проекте является обсуждение поведения создаваемого программного обеспечения или функции. Клиент или деловой человек подходит к кому-то из команды разработчиков и объясняет, чего они хотят.

Иногда эти взаимодействия приходят в форме пользовательской истории Agile. Иногда они приходят в виде проектной документации, как в прошлогодней записи в блоге Криса Фокса. Они также могут быть в виде блок-схем или макетов в Keynote или даже в виде поспешных телефонных звонков.

Только благодаря этим сообщениям разработчик несет ответственность за создание системы, которая «просто работает». Это особенно сложно для фрилансеров, работающих за пределами более крупной системы.

Почему тестирование сокращается?

Здесь есть очевидный пробел: если владелец бизнеса предусмотрел поведение системы с самого начала, почему проверка того, что это поведение действительно работает , часто является шагом, который сокращается?

Ответ может быть ослепляюще простым: тесты часто не рассматриваются как общий капитал ; они не считаются имеющими ценность для проекта, потому что «они предназначены только для инженеров» или, аналогичным образом, представляют ценность для одного отдела или группы людей.

Как мы можем протестировать этот общий капитал, этот список поведения системы? Охватывая не только разработку, управляемую тестированием (TDD), но и разработку, управляемую поведением (BDD).

Что такое БДД?

Разработка, основанная на поведении, должна быть сосредоточена на бизнес-поведении, которое реализует ваш код: «почему», стоящем за кодом . Он поддерживает командно-ориентированный (особенно кросс-функциональный) рабочий процесс.

Я видел, как agile BDD работает очень хорошо, когда разработчик и либо владелец Agile-продукта, либо бизнес-аналитик садятся вместе и пишут ожидающие спецификации (которые позже заполняются разработчиком) в обычном текстовом редакторе:

1. Деловой человек указывает поведение, которое он хочет видеть в системе.
2. Разработчик задает вопросы, исходя из своего понимания системы, а также записывает дополнительные действия, необходимые с точки зрения разработки.

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

Я обнаружил, что это простое действие дает мне достаточно ограничений, чтобы я мог думать как разработчик: «учитывая, что я должен реализовать эти тесты, как это ограничивает меня/всех в спецификации, которую я могу реализовать в коде»? Поскольку они находятся на рассмотрении, их можно быстро и легко написать в разгар совместной работы.

Этот совместный подход позволяет мне сосредоточиться на том, что эта функция дает конечному пользователю, а присутствие делового человека заставляет меня говорить о поведении, а не о реализации. Это подчеркивает различия между BDD и TDD.

Давайте посмотрим на пример разработки, основанной на поведении.

Сценарий: вы разработчик в команде, отвечающей за систему бухгалтерского учета компании, реализованную на Rails. Однажды деловой человек просит вас внедрить систему напоминаний, чтобы напоминать клиентам об их ожидающих счетах. Поскольку вы практикуете BDD в соответствии с этим руководством; (в отличие от TDD), вы садитесь с этим деловым человеком и начинаете определять поведение.

Вы открываете текстовый редактор и начинаете создавать ожидающие спецификации для поведения, которое хочет бизнес-пользователь:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Этот акцент на поведении во время разработки делает тест полезным как подтверждение того, что вы создаете правильную функцию, а не только правильность вашего кода. Обратите внимание, что фраза написана на деловом языке, а не на языке внутренней реализации системы. Вы не видите и не заботитесь о том, что счет belongs_to учетной записи, потому что никто за пределами команды разработчиков не заботится об этом.

Некоторые разработчики предпочитают писать тест-кейсы на месте, вызывая методы в системе, настраивая ожидания, например так:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

Набор тестов завершится ошибкой, потому что мы еще не написали код для установки reminder_date .

Несоответствующие спецификации

Я понимаю разработчиков, которые пишут плохие спецификации, но с бизнес-человеком рядом со мной это никогда не срабатывало. Неподходящий деловой человек либо отвлечется на детали, либо возьмет эти новые знания и попытается микроуправлять вещами, о которых разработчик знает больше (правильное проектирование базы данных, повторное использование кода).

По моему опыту, написание более чем однострочного обзора конкретного поведения утомит делового человека. Они будут рассматривать это как нерациональное использование своего времени или будут стремиться описать следующее поведение, пока оно у них на уме.

Чем BDD отличается от TDD?

Давайте посмотрим на это по-другому, используя подход Test-Driven Development, и выпишем незавершенные тесты:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

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

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

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

 a = 42 a.should == 42

Этот формат облегчает чтение в дальнейшем. Но помните, что мы здесь не этим занимаемся — цель состоит в том, чтобы как можно быстрее снизить поведение — и обеспечить соблюдение принципа «одно проверенное поведение для каждой спецификации». В идеале название ожидаемой спецификации должно сообщать вам, что вы тестируете.

BDD — это не причудливые способы проверки ваших результатов; речь идет об обмене ожидаемым поведением между всеми членами команды.

Развитие, основанное на поведении, — это сотрудничество и общение

Давайте вернемся к нашему сценарию: работа над системой бухгалтерского учета компании.

Вы проходите через функциональность предмета с деловым человеком, когда вы анализируете систему через ее внутренности (как объекты сочетаются друг с другом внутри), а они анализируют систему снаружи.

Вы думаете о некоторых условиях и спрашиваете бизнес-аналитика, что происходит в следующих сценариях:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

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

Таким образом, Behavior-Driven Development — это инструмент, помогающий сотрудничеству и инициирующий диалог между двумя отделами. Это также способ уточнить объем желаемой функции и получить более точные оценки от команды разработчиков. Возможно, вы понимаете, что невозможно рассчитать 10 рабочих дней с заданного момента времени; это дополнительная, отдельная функция, которую вам нужно реализовать.

У разработчиков будут соображения разработчика («Что именно вы имеете в виду, когда говорите «день»?»), в то время как у деловых людей будут свои собственные соображения («Пожалуйста, не используйте здесь термин просроченный, это означает что-то другое»). То, что одна или другая группа уходит и пытается написать эти тесты бизнес-логики самостоятельно (обещание Cucumber), исключает ценный вклад каждой стороны.

Это также хорошая замена, когда Agile Client больше физически не находится в комнате: иметь свои пожелания на бумаге, смешанные с анализом (и переводом) разработчиком того, что вы строите.

Проектная документация

В более ранней публикации в блоге Toptal Крис Фокс рассказывает о проектных документах, особенно в начале проекта. Понимание и извлечение бизнес-поведений уменьшается от проектов, где система в некоторой степени известна, до тех, которые требуют десятилетий программистских лет для выполнения и имеют сотни или тысячи поведенческих спецификаций.

В статье Криса также упоминается поведение элементов на экране, и в этой области у меня постоянно возникают разногласия с дизайнерами: «Как выглядит эта кнопка, когда она тусклая» или «Как это выглядит на 11-дюймовых экранах, потому что эта страница явно предназначена для 24-дюймовых экранов?» Этот обмен данными с деловым человеком может найти пробелы в графических ресурсах проекта или макете страницы.

В очень больших кросс-функциональных командах есть много членов команды со своими собственными проблемами: дизайнеры, разработчики, потенциально кто-то из эксплуатации, администратор базы данных — возможно, специалисты по обеспечению качества (да, в TDD и BDD есть место для всех!), каждый со своими заботами и вопросами. BDD может стимулировать это сотрудничество больше, чем разработка через тестирование. Из «что происходит, когда данные слишком велики для этой таблицы?» до «Хммм, это будет дорогостоящий запрос, мы хотим его как-то кэшировать» до «Подождите, должен ли пользователь видеть всю эту конфиденциальную информацию?», на карту может быть поставлено больше, чем просто разработчик и бизнес-аналитик с вопросами об этой новой функции

Разработка, основанная на поведении, связана с общими артефактами.

Что такое общий артефакт?

Мне нравится думать об «артефактах» в разработке программного обеспечения как о потенциально физических вещах, которые описывают проект или проектную команду и которые можно найти через шесть месяцев. Хорошие артефакты объясняют, почему вещи такие, какие они есть.

Разговоры в коридоре — не артефакты. И не рисунки на доске. Чертежи на доске, которые превращаются в большие объемные учебные документы или проектные документы, — это артефакты. Протоколы совещаний тоже артефакты.

Артефакт — это некоторый исходный код, сохраненный в репозитории или общем пространстве, и тикеты в системе тикетов, или заметки во внутренней вики, или даже постоянные журналы чата.

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

Как вы используете их в BDD?

Поведение должно быть общим артефактом команды — тесты не должны быть просто рутинной работой для программистов! Хотя лучше иметь систему, в которой вся команда может легко просматривать текущие спецификации (возможно, система развертывания также извлекает и сохраняет список вариантов поведения в приватной области сайта или на вики), вы также можете делать это вручную каждый раз. спринт.

Суть игры такова: «Помогите разработчикам создать спецификации, которые нам нужны, чтобы быстрее обеспечить ценность для бизнеса, сотрудничать между отделами и делать более точные оценки».

Это общекорпоративное понимание того, что делает система, также является формой капитала. Это «почему» для «как» кода.

Заключение

Как мы решаем проблему поставки ошибочного программного обеспечения клиентам? Убедившись, что тестирование не рассматривается как нечто, «о чем заботятся только разработчики».

Описание и понимание потребностей системы имеет массу преимуществ помимо корректности кода: налаживание межведомственного диалога и обеспечение учета интересов всех заинтересованных сторон (а не только заинтересованных сторон с громкими титулами). Использование разработки, основанной на поведении, для понимания этих потребностей с самого начала и тестирование внешнего бизнес-поведения, о котором заботится вся команда , — это отличный способ обеспечить качественный проект.