Artyom Karpov

This is a popular book from 1999 that has not lost its value, even now. It was created by coders who developed their applications in the 1980s and 1990s. It seems the authors gained more success as writers or speakers than as actual programmers. As the title suggests, it is about how to become a productive programmer and the rules for doing so. These rules range from general principles (like fixing a ‘broken window’) to specific techniques (like using postconditions).

Most of the time, it is better to think through your own examples to connect the dots and remember the concepts, but the book’s examples can also be helpful. The book offers some enlightening thoughts about programming philosophy, such as the idea that the primary material we work with is plain text, and therefore we must master the right tools.

I use the rules from this book in my everyday work and strongly recommend it to any programmer, regardless of their programming language or platform. Below are my notes from the book.

(Прим. Оригинал статьи на http://dannorth.net/introducing-bdd. Дэн Норт — преподаватель agile методологий разработки. Разрабатывает ПО и учит этому около 20 лет. Создатель собственного агентства по консультированию и разработке ПО. Ввел понятие разработка через поведение (BDD). Опубликовал этот перевод на Хабре здесь.)

История: Эта статья впервые появилась в журнале Better Software в марте 2006. Она была переведена на несколько языков.

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

Чем больше я пользовался TDD, тем больше я понимал, что не столько оттачиваю своё мастерство, достигая новых его вершин, сколько то, что это было движение в слепую. Я помню, как мне все чаще приходила мысль: “Эх, вот бы мне кто-нибудь сказал это раньше!”, чем мысль: “Отлично, дорога ясна”. Я решил, что нужно найти способ обучать TDD, показывающий, как верно работать с ним сразу и без ошибок.

И этот способ — это программирование через поведение. Оно выросло из выработанных agile практик и призвано сделать их доступнее и эффективнее для команд, незнакомых с ними. Со временем, BDD стало включать в себя agile анализ и автоматическое приемочное (прим. acceptance) тестирование.