TDD, BDD и OOP?
В свете последних веяний когда к ТДД добавли БДД
интересует вопрос как там получается с ООП?
Вопрос возник из того, что БДД чисто процедурная спека.
Делать ТДД по БДД - вроде как нормально.
А вот переводить БДД в ООП, тем более - иерархию калссов,
как-то не выходит. Я имею в виду более/менее формальный
переход.
Для начала надо понять, что ТДД - это концепция тестирования при которой сначала делаются тесты, потом пишется код.
Применять эту технологию можно где угодно.
Задача: Например, ты хочешь получать дистиллированную воду.
Шаг 1: делаешь устройство, которое проверяет примеси в воде.
Шаг 2: Берешь чан, приделываешь к нему краник.
Шаг 3: Наполняешь чан водой из под крана. Берешь воду из краника и получаешь результат (красный)
Шаг 4: Перед краником ставишь необходимое оборудование.
Шаг 5: Наполняешь чан водой из под крана. Берешь воду из краника и получаешь результат (зеленый)
Юнит-Тестирование не есть ТДД, однако юнит-тестирование можно в рамках концепции ТДД.
Тоже самое с БДД. Эту технологию также можно использовать в рамках концепции ТДД.
В последнее время говоря о ТДД часто подразумевают юнит-тестирование, однако это далеко не одно и тоже :)
на одном уровне абстракции с интерфейсами
-----
Или нету, или Я не вижу. Но скорее - нету.
БДД, по определению, документ из трех частей, описывающий базовые хотелки в виде процедур.
От этого документа есть беспроблемный переход к ТДД - там тоже процедурная парадигма.
А вот с перехдом к ООП - затык - там iнтерфейсов нет.
БДД, по определению, документ из трех частей, описывающий базовые хотелки в виде процедур.
Что ты имеешь в виду?
От этого документа есть беспроблемный переход к ТДД - там тоже процедурная парадигма.
ТДД к процедурной парадигме не имеет никакого отношения.
А вот с перехдом к ООП - затык - там iнтерфейсов нет.
Интерфес - это всего лишь абстракция. В C++ интерфейсов тоже нет (или уже ввели?).
Вот например есть некий класс калькулятора:
public class Calc
{
public int Add (int a, int b)
{
return a + b;
}
}
BDD тест можно описать так:
Story: Add two values As a calculator user I want to add two integers. Scenario 1: Add zero to a value Given I've created an instance of calculator And my first term is 15 When I've added 0 Then I should have 15 Scenario 2: Add two non-zero values Given I've created an instance of calculator And my first term is 5 When I've added 7 Then I should have 12
У такого подхода есть свои плюсы. В первую очередь, тесты могут писать далекие от программирования люди, но зато понимающие предметную область.
Минусы тоже есть - перед тем как получится эффективно внедрять этот метод архитекторам придется изрядно поработать как со специалистами в предметной области, так и с программистами, чтобы выработать единый язык. Но это уже чистое DDD 
БДД ... можно описать так
-----
Теперь пишем еще 3 спеки - Sub, Mult, Div.
Имеем 4 разных документа.
Немного думаем и рожаем еще 12 документов:
- 4 для работы с последним полученным результатом
- 8 для работы с шестнадцатричным числами.
Раскидываем эти документы по подразделеням для параллельной разработки
Требуется - перейти к обьекту Калькулятор...
ТДД к процедурной парадигме не имеет никакого отношения.
-----
Да ладно...
Чистейший набор описаний процедур для получения ожидаемого результата.
Единственное отличие от алгоритма - не требуется заданный результат допусается множество хотелок.
Ну да это не суть - как к структуре обьектоv и иерархии классов переходить?
В C++ интерфейсов тоже нет (или уже ввели?).
-----
Абстрактные классы есть...
Теперь пишем еще 3 спеки - Sub, Mult, Div.
Имеем 4 разных документа.
Интересный подход. Впрочем, если у тебя по каждой фиче всегда отбельный документ, то это же твоя проблема, а не BDD ;)
Требуется - перейти к обьекту Калькулятор...
Неее, тебе требуется наплодить как можно больше документов :) А что ты понимаешься под "перейти к обьекту Калькулятор" вообще ни секунды не понятно.
Чистейший набор описаний процедур для получения ожидаемого результата.
ТДД - это подход к разработке чего-либо, при котором сначала делаются тесты.
Ну и если исходить из того, что ты только что сказал, то ООП - это тоже процедукная парадигма, т.к. в классах есть процедуры, которые надо вызывать для получения ожидаемого результата.
Ну да это не суть - как к структуре обьектоv и иерархии классов переходить?
Никак,
ТДД не имеет никакого отношения ни к объектам, ни к их структуре, ни к иерархии классов.
а не BDD ;)
-----
Там аккурат 3 дополнительные Стори, как ты ее определил...
вообще ни секунды не понятно
-----
Вот и мне непонятно где непонятно...
Никак, ТДД не
-----
Перечитай еще раз - меня не ТДД -> ООП интересует, а БДД -> ООП.
Т.е. из документрованных хотелок в иерархию классов.
хоть на функциональном хоть на ассемблере могу реализовывать
-----
Ну вот меня и интересует один конкретный вариант - из БДД в иерархию классов/интерфейсов.
Что можно нарисовать какой-то метод - оно понятно.
Что метод можно (а где-то - нужно) упаковать в класс - тоже не сложно осознать.
А сколько классов должно быть? Что пойдет в базовые классы? Что - в интерфейсы?
Конкретный рецепт: возьмите две чайных ложки архитекторов, добавьте описание поведения, измельчите, залейте водой и тщательно прокипятите в течение 10 часов.
А потом вылейте это всё нахрен.
Потому что описания поведения недостаточно для создания архитектуры.
Если в рамках существующего приложения... Можно пнуть сениора. Он "переведёт". Формализовать не получится.
Там аккурат 3 дополнительные Стори, как ты ее определил...
И чО? :)
Вот и мне непонятно где непонятно...
Так зачем же ты произносишь слова, смысл которых ты не понимаешь? :)
Если я правильно понимаю, то
ТДД -> ООП
никаких вопросов у тебя не вызывает?
БДД -> ООП
Это такая же глупость, как и ТДД -> ООП.
Исходя из того что у меня розовая юзерка возникает вопрос - на чей именно хрен лить?
Ну как математику не учил. Пришить. И свести проблему к уже решённой.
Следующий вопрос - чем заменить БДД чтобы получалось?
Ничем. Как только решишь - 95% программистов не нужны будут. Добро пожаловать в мир влажных фантазий "Documentation as code".
