Модели разработки программных средств TDD, BDD и TFD. Отличия и способы применения.

Модель - искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. Считается, что М моделирует А, если М отвечает на вопросы относительно А. Здесь М - модель, А - моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Модель описывает, что происходит в системе, как ею управляют, что она преобразует, какие средства использует для выполнения своих функций и что производит.

TDD — Test Driven Development

TDD - это методология разработки ПО, которая основывается на повторении коротких циклов разработки: изначально пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволит пройти написанный тест. Затем проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов. TDD считается одной из форм правильного метода построения приложения. Философия разработки на основе тестов заключается в том, что ваши тесты являются спецификацией того, как ваша программа должна вести себя. Если вы рассматриваете свой набор тестов как обязательную часть процесса сборки, если ваши тесты не проходят, программа не собирается, потому что она неверна. Конечно, ограничение заключается в том, что правильность вашей программы определена только как полнота ваших тестов. Тем не менее, исследования показали, что разработка, основанная на тестировании, может привести к снижению ошибок на 40-80% в производстве.

Эта методология позволяет добиться создания пригодного для автоматического тестирования приложения и очень хорошего покрытия кода тестами, так как ТЗ переводится на язык автоматических тестов, то есть всё, что программа должна делать, проверяется. Также TDD часто упрощает программную реализацию: исключается избыточность реализации — если компонент проходит тест, то он считается готовым.

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

BDD — Behaviour Driven Development

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

TFD-Testing First Development

TFD - вместо традиционного ATPG, чтоб подчеркнуть двойственность DFT &TFD в разработке тестового обеспечения (TestWare).Термин “ - тестовое обеспечение ” (TestWare) соединяет все составляющие качественного тестирования, четко разъясняя заказчику, из чего складывается качество теста для его схемы:

• верифицирован ли проект?
• правильно ли работают шины и двунаправленные магистрали?
• нет ли избыточности, препятствующей достижению высокого качества теста?
• тестопригодна ли схема настолько, чтоб автоматически сгенерировать тест?
• можно ли и, самое главное, как и где изменить схему так, чтобы сделать возможной ATPG?
• каков прогноз качества теста в ATPG?
• что получит разработчик для схемы с рекомендованными изменениями?
• что получит разработчик для исходной схемы, если она недостаточно тестопригодна?

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

• уверенный прогноз качества теста по оптимистическим оценкам тестопригодности в зоне уверенной генерации теста
• эффективность процедуры генерации теста регулярным методом вычисления последовательностей, свободных от состязаний
• экономичность генератора тестопригодных модификаций на базе оценок управляемости и наблюдаемости, пропорциональных затратам на вычисление теста и построенных по принципу “выше оценка – выше сложность”

Способы реализации

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

• Парсер может разбить спецификацию по её формальным частям, например по ключевым словам языка Gherkin. На выходе мы получаем набор предложений, каждое из которых начинается с ключевого слова.
• Каждое предложение может выражать один шаг теста.
• Некоторые части предложения могут являться входными параметрами, которые можно захватить, а остальные части могут никак не использоваться и служить только для понимания действия человеком. Обычно для такого захвата используется процессор регулярных выражений. Захваченные параметры могут быть переконвертированы и отправлены на вход конкретной исполняющей функции.

Минусы

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

Плюсы

• Тесты читаемые для не программистов.
• Их легко изменять. Они часто пишутся почти на чистом английском.
• Их может писать product owner или другие заинтересованные лица.
• Результаты выполнения тестов более "человечные".
• Тесты не зависят от целевого языка программирования. Миграция на другой язык сильно упрощается.

Отличия

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

• TDD хорошо подходит для юнит-тестирования, т.е. для проверки работы отдельных модулей самих по себе. BDD — для интеграционного (т.е. для проверки, как отдельные модули работают друг с другом) и e2e (т.е. для проверки всей системы целиком) тестирования.
• TDD: тесты сразу реализуются в коде, для BDD чаще всего описываются шаги на языке, понятном всем, а не только разработчикам.
• TDD: юнит-тесты пишут сами разработчики. BDD требует объедения усилий разных членов команды. Обычно тест-кейсы (шаги) описываются ручным тестировщиком или аналитиком и воплощаются в код тестировщиком-автоматизатором. В нашей команде фронтенедеры описываем шаги вместе с тестировщиками, а код тестов пишет фронтенд-команда.
• TDD проверяет работу функций, BDD — пользовательские сценарии.

Пример

Нужно сделать форму, в которую мы вводим возраст кота и его вес, а в ответ получаем, сколько корма кот должен кушать в сутки Как подойти к этой задаче, используя TDD подход:

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

Как подойти к этой задаче, используя BDD подход:

• Процесс начинается с того что пользователь открывает форму
• Нам нужно протестировать числа которые выдает форма
• Нам нужно ввести 10–20 разных значений
• Проверка в данном случае это нажатие на Submit кнопку и проверка значения
• Тест пройдет если результат на форме соответствует “правильным” значениям

Далее мы это описываем с помощью специального синтаксиса (он зависит от инструмента, который используем, но суть одна). Например:

• Функция: Расчет количества корма
• Сценарий: При вводе валидных параметров отображается правильный ответ
• Когда я нахожусь на странице с формой
• И ввожу возраст 5 лет
• И ввожу вес 5 кг
• То мне отображается количество корма 500 г

Потом эти шаги реализуются в коде.

Источники:

Основные понятия

Методология функционального моделирования

Примеры и отличия

Выполнил: Поздеев Виктор ИДБ-17-07

Проверил: Филиппов Юрий ИДБ-17-07