Исправил проблему с тэгами, оказывается дело в < > символах в тексте cucumber feature

Для тех, кому интересно покопаться в реализации самому, милости прошу на GitHub. Все три BDD frameworks представлены в этом проекте, собственно это полигон для этой статьи. Кроме того, можно поглядеть сюда, чтобы увидеть как работает Spock в связке с Selenium2/webdriver + Geb.

«некомпилируемых фреймворков», что вы имели в виду? Буду ли я прав если предположу, что вы говорите о динамических языках программирования?

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

Да, нельзя быть ни в чем быть на 100% уверенным. Все упирается в качество автоматизированных тестов. Заметьте не только степень покрытия, Unit тестами, кода, но и Acceptance тесты. Когда вы пишите Unit тест, вы подтверждаете правильность реализации с точки зрения разработчика, Acceptance тесты подтверждают то, что вы реализовали именно то что хотел бизнес. Иными словами Unit/Integration тесты для разработчиков, Aceeptance для всех остальных.
Поверьте, если у вас разумно написаны тесты всех уровней пирамиды тестирования, то творить с кодом все, что угодно они вам просто не позволят.

Да, я не учел, что можно считать кумулятивную сумму.
Вот моя реализация на Java на github.

Я честно сознаюсь что не читал эту книгу. Дело в том, что Гойко Аджич приезжал к нашему заказчику и консультировал его, кроме того к нам в Киев приезжал Craig Larman, и в течении спринта присутствовал на всех PBR и других Scrum Events.
Вот несколько моментов которые мне запомнились
1. Во время PBR заказчику советовали тестировать нас, то есть через каждые 5 минут заказчик задавал нам вопросы по SBE и мы на них отвечали, иными словами мы сами участвовали в их построении.
2. Старайтесь использовать tools и environment для совместного построения SBE — в нашем случае это был SmartBoard и… Google Docs. Звучит забавно, но вы можете совместно писать SBE именно там.
3. Используйте общий язык, который понятен, как заказчику так и вам, это было еще в DDD Эрика Еванса
4. От себя. SBE можно положить на исполняемые тестовые сценарии. Что я и пытаюсь продвинуть у себя в проекте

ЗЫ. подборка внушительная, нужно будет ознакомиться подробнее.

Это уже интеграционные тесты или даже Unit. В функциональных тестах вы запускаете систему на реальное базе, по крайней мере должны к этому стремиться, единственное, что в функциональных тестах может быть недоступно, это сторонние системы с которыми вы взаимодействуете. Что такое ФС?
С унаследованным кодом часто бывают такие проблемы, как невозможность нормально замокать/стабить какую-то абстракцию. Отсюда необходимость рефакторинга в таком объеме.
Если вы обратитесь к Continiuos Delivery (не путайте с Continious Integration), то вы увидите паттерн Branch By Abstraction. Так вот применить этот подход особенно сложно когда код лапшеобразный, то есть, изменив, что то в одном месте проблемы вылазят совершенно в непредсказуемых местах. Все это немного из другой оперы но, тем не менее упирается в построение тестов.

политичеCукий — исправил. Ненамеренно, хотя по Фрейду.
Оценки user story мы делаем совместно с заказчиком, и потом усредняем либо спорим если были большие расхождения. Я говорю про более детальную разбивку user story по tasks. Что то типа «добавить валюту для матчинга трейдов с конфирмейшенами». Понять, что тебе нужно добавить поле валюты на этапе оценки user story в story point не всегда представляется возможным.
Оценка User Story (US) в Story Points (SP) более поверхностна, и не должна занимать много времени, и как правило может быть проведена после PBR.

По поводу второго пункта, подумалось вот что: если много рефакторите, чтобы можно было подсунуть моки или стабы то скорее всего проектирование и дизайн и потом разработка не соответвовала SOLID правилам, нужно подумать над technical dept. Может TDD, ибо при этом подходе ты всегда уверен что любой код был написан благодаря упавшим тестам.
Кроме того функциональное тестирование, как праило подразумевает мокание сторонних систем с которыми вы взаимодействуете или UI.

Возможно Вашь алгоритм можно улучшить, в случае если L>=R. В случае если это условие выплняется, то sqrt суммы для R частично считать не нужно, они уже посчитаны для L.
Кроме того, если бы в статье были приведены примеры Unit тестов то материал был бы более усваиваем.