Tdd что это такое

Что такое TDD и BDD на пальцах, и что должен знать о них фронтендер

Dec 18, 2019 · 3 min read

Постараюсь как можно проще объяснить эти концепции и на примере показать разницу.

❓Что это вообще за буквы

И то, и другое — подходы к разработке, когда сначала пишутся тесты, а потом код.

*DD (*что-то* Driven Development) — разработка, основанная на чем-то.

TDD (Test Driven Development) — Разработка на основе тестов.

BDD (Behavior Driven Development) — Разработка на основе поведения.

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

❓В чем разница

❓А как выглядит на примере

Давайте во з ьмем простую задачку. Нам нужно сделать форму, в которую мы вводим возраст котика и его вес, а в ответ получаем, сколько корма котик должен кушать в сутки.

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

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

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

Функция: Расчет количества корма

Сценарий: При вводе валидных параметров отображается правильный ответ

Когда я нахожусь на странице с формой

И ввожу возраст 5 лет

То мне отображается количество корма 500 г

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

❓ Я фронтендер, зачем мне это надо

Умение тестировать свой код — очень жирный плюс для фронтендера, и вот почему:

PS В следующем посте расскажу об инструментах, которые мы используем для тестирования, и как у нас построен процесс.

Источник

Опыт работы с TDD и размышления о том, как надо тестировать код

Недавно в нашей фирме устроили лекцию «Engineering Practices» и это оказалось введением в TDD.
О нет, только не это! «Иногда они возвращаются» (с) Стивен Кинг

На прошлой работе мы потратили 3 года на попытку внедрить эту методику. Это было мучительно. Менеджмент искренне верил в то, что TDD решит проблемы фирмы. Реальность разительно несоответствовала этому. Все это будило затертые воспоминания о Советской эпохе. Вспоминались висящие на стенах плакаты «Вперед к победе коммунизма» и фразы вроде «Учение Маркса всесильно потому, что оно верно».

Так что же не так в консерватории c TDD?

Дисклаймер

К сожалению, мой пост многими был понят в том смысле, что я против тестирования. И особенно против юнит тестов во всех их проявлениях. Это не совсем так, точнее это совсем не так.

Для начала, определимся с терминами.

Терминология

Ручные тесты (Manual tests)
Функционал тестируется вручную на «живой» системе, использую стандартный для нее UI.
Это обычный, традиционный метод тестинга для QA.

Функциональные тесты (Functional tests)
Программист пишет некое «тестовое» UI, которое позволяет запускать определенные сценарии на «живой» системе, с взаимодействием настоящих модулей.
Это весьма распространенный метод тестирования, используемый программистами.

Юнит тесты (Unit tests)
Программист пишет тесты, которые способны выполняться в «изолированной» среде – без других модулей. Прочие модули, к которым в процессе работы, должен обращаться тестируемый код, заменяются на на Моки (mocks). Таким образом, тесты могут исполняться в автоматическом режиме, на билд-машине, после компиляции.
Существует тренд на использование таких тестов. И программисты испытывают давление (моральное и административное), с тем чтобы перейти на их использование.

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

«Ошибка в коде»
Код написан с ошибкой и делает нечто, отличное от намерения программиста.

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

«Ошибки мультисрединга и тайминга»
Если в работе учавствуют несколько тредов (threads), возможны ошибки, связанные с доступом к общему ресурсу или с последовательностью вызовов. Это самые трудноуловимые (после memory corruption) баги, с которыми мне доводилось сталкиваться.

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

Плюсы и минусы различных видов тестирования

Согласно моему опыту (точной статистики не имею, к сожалению), «ошибки в коде» составляют менее 30% всех багов в достаточно сложной системе. Если программист достаточно опытен, количество таких ошибок будет еще меньше.
Подавляющее большинство таких ошибок отлично ловятся с помощью «инспекций кода» (code review) и функциональных тестов.

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

Наиболее сильная сторона юнит тестов – автоматизация.
Но вот лично я (за 3 года работы) не сталкивался с ситуацией, когда юнит тесты помогали найти баг спустя достаточно большое время после его написания.
То есть юнит тесты эффективны (помогают найти баги) исключительно короткое время после написания.
Я ни разу не видел, чтобы автоматически запускаемые на билдере юнит тесты что-то отловили. Они там «чистят чистое». Ну и, конечно, служат душевному спокойствию руководства. 🙂

Минус юнит тестов – громадные усилия, которые приходится затрачивать на написание и программирование моков. Именно поэтому время, потребное на разработку с использованием юнит тестов в 2-5 раз больше чем без них.

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

Организацинные и психологические моменты

Вопрос на засыпку: кто и как может убедиться, что программист написал юнит тесты достаточно хорошо?

Существует два возможных варианта проверки юнит тестов:
Инструменальная проверка
Существует возможность измерить «покрытие» кода тестами – все ли строчки кода выполнялись в рамках тестов. Я ни разу не видел, чтобы такая проверка использовалась. Ну и, разумеется, такие тесты могут проверить, что тесты «покрывают» код, но не могут проверить, что тесты «покрывают» возможные входные данные.

Инспекция юнит тестов другим программистом или руководителем
Я видел как это делается. Писать юнит тесты – весьма занудное дело. Разбираться в них – вообще мрак. То есть, можно разобраться, но это требует серьезного количества времени и мотивации. В самом начале внедрения, у людей был интерес и мотивация сделать все как надо, чтобы разобраться что это такое – юнит тесты и TDD. Но очень скоро это прошло.

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

Если программист упускает что-то в коде, ее ловят в QA или уже у клиента и баг возвращается для исправления. Обратная связь заставляет относиться к коду серьезно и внимательно.
Если программист упускает что-то в написании тестов, это фактически никто никогда не заметит. Отсутствие обратной связи позволяет относиться к вопросу наплевательски.
Даже если программист получил в пять раз больше времени на разработку, я он скорее пойду пойдет почитать Хабрахабр, вместо того чтобы дотошно выпиливать лобзиком тесты, моки, тесты, моки… и так много дней подряд.

Как же еще можно заставить юнит тесты «работать»? Они должны работать если тесты будут писаться другим программистом, причем лучше всего до самого кода.
И тут мы приходим к TDD.

Test Driven Development

Если тест написан до и предоставлен программисту в качестве исходных данных, он становится «техническми требованием» (requirement). Разумеется, тот кто пишет тест, должен заранее написать и запрограммировать все требуемые моки. Ха-ха, не хотел бы я быть тем программистом, в обязанности которого входит программировать тесты для других.

Ну, а может ли сам программист написать тесты к своему коду заранее?
По моему опыту, нет и нет. Программисты (и я и подавляющее большинство, с кем я это обсуждал) просто думают в обратном направлении.

Да, поначалу люди пытались честно следовать методологии. Но спустя какое-то время, начинали сначала писать код, а потом на него дописывать тесты. А еще спустя какое-то время, тесты потеряли свою разносторонность и дотошность. А потом и вовсе писались «штоб было», раз уж просят.

Источник

TDD: Что пошло не так?

Эта статья является переводом материала «TDD: What went wrong or did it?».

В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).

Как это возможно, что одна и та же техника, которая так выгодна для стольких разработчиков, так губительна для других? В этой статье Владислав Кононов расскажет о трех заблуждениях, которые могли бы объяснить это явление.

Начнем с самого тонкого и самого деструктивного.

TDD это не «Проектирование через тестирование»

TDD расшифровывается как “Разработка через тестирование”. К сожалению, многие неверно истолковывают это как “Проектирование, основанное на тестировании”. Эта неточность может показаться невинной, но поверьте мне, это не так. Позвольте мне объяснить.

Если вы разрабатываете в первую очередь для тестируемости, вы получаете то, за что платите, — тестируемый код. Чаще всего этот дизайн будет полностью не связан с бизнес-областью и требованиями проекта. Он будет напоминать огромный граф объектов, полный случайных сложностей. но он будет проверяемым. Тестируемый тестами, которые тонут в моках (имеется в виду mock как тестовый двойник), и полностью сломается после изменения одного кусочка в реализации. Это то, что называется “повреждением, вызванным тестом”, и это ярко показано в блоге Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.»:

Нынешний фанатичный опыт TDD приводит к тому, что основное внимание уделяется модульным тестам, потому что это тесты, способные управлять дизайном кода (первоначальное обоснование для test-first – сначала тестирование, потом реализация). Я не думаю, что это здорово. Test-first приводят к чрезмерно сложной сети промежуточных объектов и косвенных обращений, чтобы избежать «медленных» действий. Например, попасть в базу данных. Или файл IO. Или пройти через браузер, чтобы протестировать всю систему. Это породило некоторые поистине ужасные архитектурные уродства. Густые джунгли служебных объектов, командных шаблонов и прочего.

TDD это не (только) о модульных тестах

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

Вы имеете дело со сложной бизнес-логикой? Вам действительно нужны модульные тесты здесь.

Вы выполняете только простые операции CRUD? Используйте интеграционные тесты или сквозные тесты.

Сценарий ETL? Достаточно сквозных тестов.

. И, говоря о модульных тестах, что вообще такое модуль? Переходим к третьему заблуждению.

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

Определение модуля, которое мне нравится больше всего, принадлежит Рою Ошерову, автору книги The Art of Unit Testing:

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

Отсутствие буквы D в TDD

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

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

P.S TDD 2.0

TDD был «заново открыт» Кентом Беком более десяти лет назад. Возможно, пора снова открыть TDD. Помимо модульных тестов, новая спецификация должна касаться других типов автоматизированных тестов, которые в то время были недоступны. И, конечно же, вместо того, чтобы работать против, TDD должен тесно сотрудничать с бизнес-областью.

Источник

Test-Driven Development — телега или лошадь?

Test Driven Development (TDD) – неоспоримо выдающаяся техника, дающая ряд преимуществ. Прикладные разработчики, причём вне зависимости от масштаба проекта и количества вовлеченных специалистов, в широкой массе не следуют TDD. Но есть и ярые сторонники такого подхода, причём они готовы апеллировать не только к здравому смыслу или производственной необходимости, но и на безоговорочно успешные примеры его внедрения. Одним из таких апологетов является Александр Люлин, который не только рассказывает о степени позитивного влияния TDD на разработку, но и делится экспертизой внедрения и неукоснительного каждодневного применения этой техники вплоть до исходных кодов и примеров сценариев (в своем блоге). Однако главный тормоз на пути следования принципам TDD стоит, что предсказуемо, набор чисто психологических установок. В режиме «жёсткого разговора» мы пообщаемся с Александром на тему необходимости Test Driven Development.

Test Driven Development – попытка следования моде? Слепое копирование чужих подходов?

Давайте «сразу определимся». Я не использую TDD в его классическом понимании. И не надо здесь цитировать «википедию»! Вообще, вряд ли кто-то из профессионалов рассматривает энциклопедические статьи в качестве руководства к действию. Мы свой подход «выстрадали» в рамках реализации успешного проекта, поэтому за нами реальный опыт, а не «тупое использование чужих идей». Скорее, мы используем синтез из TDD и собственных представлений о том, как нужно разрабатывать ПО. Даже если эти «внешние идеи» исходят от очень умных людей, их следует критически осмыслить и адаптировать к реальной компании, существующей команды и стратегии развития и обеспечения качества. Но я далее буду говорить «TDD», имея ввиду тот процесс “разработки через тестирования», который близко соотносится с энциклопедическим Test Driven Development, но идёт гораздо дальше него.

TDD — это попытка поставить всё с ног на голову. В классике инженерного дела сначала создаётся установка/техническая система/машина/агрегат. Конечно, методика испытаний имеется в виду при проектировании… но всё-так, программисты – это какой-то особый вид инженеров? Генетически ущербных? Сами себя таким не считаете?

Тут всё зависит от определения — что «голова», а что «ноги». И как известно самый научный спор — это спор о терминах. Если говорить о методики испытаний как самодостаточной и глубоко проработанной дисциплине, то нельзя сказать, что она есть в промышленных масштабах. Тогда бы она де-факто присутствовала везде и никакой полемики не было бы в принципе. Но это, собственно, не отличает нас принципиально от других инженеров, которые, например, делают кофеварки, газонокосилки или велосипеды (не путать с «велосипедами»).

Считаю ли я себя «генетически ущербным»? В силу профессии, отчасти, да. Поэтому и стремлюсь всеми силами стать лучше. Разработка ПО – инженерное ремесло, поэтому не надо вдруг себя считать суперменом или неким творцом. Мы – ремесленники (за исключением единиц), это нужно осознать и смириться. И попытаться стать нормальным (а не генетически ущербным) инженером – допуски, чертежи, методики испытаний и т.д.

TDD — сковывает инициативу разработчика. Уже не сам разработчик контролирует процесс, а задание «валится на него снеговыми комками»? Нет ли психологического дискомфорта? Программист у нас теперь не творец, а бездумная машина реализации им функционала?

Наоборот, TDD ничего не сковывает, но позволяет работать более продуктивно. Конечно, «продуктивно» означает «больше работать». Вместо одного класса приходится писать два: сам проектируемый класс и тест к нему. TDD это как раз для инициативных людей. Которые любят свою работу. Если есть желание оптимизировать (=сэкономить своё рабочее время), то это уже в дверь с надписью «для бездельников». Потенциальные бездельники или люди, практикующие безделье в рабочее время, могут дальше не читать.

Только никто не контролирует разработчика, он сам себя контролирует – «бьёт по рукам». Но это не мазохизм. Взамен разработчик получает кое-что важное – ощущение стабильности и уверенности в своём профессиональном завтрашнем дне. А как творец – он творит в два раза больше. Именно творит, а не «пашет». Пашет он как раз меньше. Жду следующего вопроса для разъяснений.

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

Вот это – совсем уж неправда. Именно качество и стабильность ставится во главу угла. Как раз, есть «фича» – есть тест, подтверждающий, что это «фича», а не «бага». Что не попало в ТЗ, то не попало в тесты, откуда тогда оно возьмётся в функционале? Только так: желание заказчика выражается в ТЗ, оттуда перетекает в тесты, и только потом появляется функционал.

Теперь про архитектуру… Архитектура это не есть что-то универсальное и самоценное. И не есть серебряная пуля. И не то, из чего делается плохая пуля. Я знаю архитектуру системы, т.к. я 15 лет ей занимаюсь и знаю великолепно, спасибо UML-чертежам. У меня полный набор проектных решений в виде UML-диаграмм. Но и здесь есть вероятность не удержать всё в памяти. Как всё это восстановить в памяти? Просто на конкретный тест посмотреть.
Тесты — это «архивированная память», а также «документация» и «варианты использования».

При этом тесты — более стабильны и инвариантны по сравнению с проектным кодом. Код перерождается. Эволюционирует. Умирает. С тестами это происходит гораздо реже. Видите, нет никакого конфликта интересов у архитектуры и тестов. И они в своей связке важнее кода.

TDD – некий бич, которым хлещут непокорных IT-рабов? Это что – некий вид «управы» на свободолюбцев, гордо именуемых «разработчиками»? Вы, разрабочтики, не должны думать. Ваша дело – тянуть лямку, выполнять план по валу! Смотри на тесты, данные тобой свыше, и не вздумай проявлять инициативу!

Значит так… «Руководству», (директорату и тем более заказчикам) реально нет дела, какие технологии используются (за редкими исключениями, на что мы надеяться не будем). Вообще, никого не парит, и что там «внутри» делают разработчики. Используют они RUP, TDD/ШмеДД, Agile/СуперАгиле или что-то иное…

Всем выше перечисленным «стейкхолдерам» – важен результат, а не процесс. Никакой здравомыслящий начальник не будет навязывать TDD. Ему нужен результат, а не раздражение разработчиков — «вот этот умник опять какие-то новомодные фишки нам навязывает». Умный начальник… реально умный (в IT это чаще, чем в других областях) может лишь сделать так, чтобы разработчики сами почувствовали эту необходимость. Это – единственный путь, иначе – тупик.

Нету никаких тестов, данных свыше. Тесты это — внутреннее дело разработчиков. И чем лучше тесты и чем их больше, тем разработчики «крепче спят». И тем меньше они вызываются на ковёр. Тесты – для разработчиков, не для начальников.

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

Ещё раз. Тесты не диктует «директорат», руководство или заказчики. Тесты — это средство разработки. Тесты это – «внутренняя кухня» разработчиков и группы качества. Все остальные «стейкхолдеры» оперируют ТЗ. Ну или «экранами». Максимум… Тесты и «стратегия развития» вообще никак не соотносятся.

Допустим, меня обязали следовать технике TDD, хотя, согласитесь, очень многие люди комфортно чувствуют себя без этого. Ну и что это даёт по сравнению с нормальной техникой, когда «запланировали – реализовали – сделали тесты – протестировали»? Просто «красивая сказка» для начальника «мы используем передовые подходы?»

Можно же быть таким упёртым противником TDD! «Обязать» использовать тесты невозможно. Можно лишь уговорить. Если кто-то чувствует себя комфортно без тестов, то значит, что:
— его проект не такой сложный;
— он всё тестирует на реальных пользователях (не повезло им)
— он гений;
— он работает один.
Давайте, посмотрим в зеркало и выберем свою категорию.

Ещё раз: «Сказки» — нет, начальству – всё равно, ему нужен результат, сроки и качество.

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

Вот «напахивать» ничего не надо. Одна фича – один тест. Итеративно. Фича порождает тест, а тест порождает фичу. XP, kiss-принцип.

А не бывает такого, что «тесты», которые приобрели вид «жёсткого задания», начали противоречить друг-другу?

Это мой любимый вопрос из разряда «гениальных»! Если тесты противоречат друг-другу, значит:
— ТЗ недостаточно проработано;
— ТЗ противоречиво.
Тут надо сказать «спасибо» тестам и вернутся к проработке ТЗ.

TDD – потеря времени. Давайте уж сначала напишем код, а потом будем его тестировать. Любое хождение «задом-наперёд», ненатуральный порядок разработки, даже если не сказывается на качестве, обязательно вызовет «тормоза».

Логично. Так многие и делают. Напишем код. Напишем. Покоммитим его в CVS/SVN. И что? Мы свою работу сделали? Типа «как повезёт»? Прокатит/не прокатит? Можно и так. Только потом тебя «поднимут с постели» и спросят «что за хрень ты тут написал?» Так?

Можно ведь по-другому — написать код и проверить его. А как мы его будем проверять? «Тупым» протыкиванием?
А если для «протыкивания» надо сделать 20-ть шагов? А если 100? А если «данных нет»? А если «смежники не готовы»? Не проще ли «написать тест» хотя бы для отладки? С придуманными «из головы» входом и выходом. По-моему, проще. А если тест УЖЕ написан и использовался для отладки, то почему не включить этот тест в «ночную сборку»?

TDD – способ поставить разработчика в унизительное положение. «Битый небитого везёт». Программист работает «от чувства вины» в перманентном состоянии нереализованности поставленной задачи.

Наоборот, у программиста есть всегда «реперные точки». Тут вот я написал тест. Он не проходит. Тут я реализовал функционал. Тест стал проходить.
Я всё покоммитил в CVS/SVN. Я свою работу СДЕЛАЛ и «могу спать спокойно».

TDD – нет ли ощущения, что программист всё время решает обратную задачу? Или разработчик – двоечник, подгоняющий решение под ответ задачи?

А программисты всегда решают обратную задачу. Ну или «строят сферического коня в вакууме». Программист – не двоечник, а обычный человек, который не может предусмотреть всё. Но зато то, что он предусмотрел – гарантировано работает. Есть и другие люди. Но они – гении, но их мало.

TDD – разработка в зазеркалье. Мы выполнили тесты, что не есть гарантия безошибочности. Кто отвечает за качество тестов?

Гарантии полной безошибочности» нет. Есть лишь гарантия того, что разработчик правильно понял ТЗ и реализовал его так, как понял.

TDD – телега впереди лошади. Лошадь постоянно тыкается мордой «в задний бампер», не видя ничего впереди себя. Как можно говорить о продумывании функционала в целом на уровне архитектуры системы, когда впереди – вдаль до самого горизонта – просто свалка потребностей?

Вот тут опять давайте вернёмся к «самому научному спору». Определим термины, что – телега, а что – лошадь. И не надо мне грозить википедией (как можно тестировать то, чего нет)?

Вот так будет правильно:
— «лошадь» — это ТЗ;
— «телега» — это КОД.

First: ТЗ и набросок архитектуры, дальше начинается итерационная разработка.
И что особенно вкусно, что как только мы написали тест, нам не надо думать, а где проверять работоспособность нашего класса? Мы уже настроили всю инфраструктуру для его тестирования и проверки. Именно это и означает слово Driven в TDD.

Ладно, есть на свете «извращенцы». Тогда хоть как можно облегчить страдания? Какой правильный процесс при этом?

Не, ну спасибо за эпитет. Цепочку я описал выше. Если мозг готов, то процесс выстроится сам собой. Дальше то вопрос в выборе инструментария.

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

Инструментарий, который мы используем:
— DUnit.
— Доработки к DUnit;
— Confluence;
— самописный аналог JIRA; в ту пору JIRA была ещё «сыра» поэтому мы её не взяли; сейчас — я думаю — взяли бы её;
— скриптовая машина;
— FishEye (https://www.atlassian.com/software/fisheye/overview);
— Доработки к Confluence и FishEye позволяющие отслеживать связь коммитов, изменений кода и строящие привязку конкретных изменений кода к конкретным задачам;
— интеграция UML и Confluence;

Кто создает тесты? А если «роль» создателя тестов не предполагает знание программирования?

Тесты создают разработчики. Если речь идёт о новой функциональности.
Или тестировщики. Если речь идёт об ошибках.
И чаще всего, тестировщики пишут ошибку и сразу пишут к ней тест.
Тут кстати надо понимать одну простую вещь, ТЗ и ошибки в общем-то ничем не отличаются друг от друга принципиально. Только лишь «зоной ответственности».
«А если «роль» создателя тестов не предполагает знание программирования?» — на BDD или Fit-таблицы — мы пока не «замахивались», но мы работаем над этим.

TDD – это наше «всё» или Вы всё-таки признаёте ограниченность данной техники?

«Разруха она в головах, а не в коде». Нет ограниченности. Есть нежелание применять.

Ко всем ли системам применима техника TDD? Есть «особые случаи» или «другие подходы»?

Нет «особых случаев». Есть желание разработчиков «спать спокойно» и не думать лишнего, сохраняя нервы.

Есть что-то что можно выкинуть из TDD, есть что-то что можно привнести. Но в целом, TDD остаётся и гарантирует отсутствие паники. Panic-Driven Development исключается.

Что привело Вас к TDD?

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

Что по-Вашему может быть лучше, чем TDD?

BDD. Есть люди в мире Delphi, которые этим занимаются и пропагандируют. Роман Янковский над этим работает. Ну и Fit-таблицы. Если есть желание развиваться, то можно до много самому дойти. Либо воспользоваться полунамёками, отрывочными статьями, википедией (в крайнем случае). Но сегодня я рассказал о реально работающем процессе. В деталях пишу в своём блоге, но общение с аудиторией доказало (выходя за рамки читателей), что главная проблема именно в понимании ценности TDD. Об этом сегодня попытался рассказать.

Ничего, что часть вопросов прозвучала как «троллинг»?

В жизни и не такое случалось, когда внедряли TDD в производственный процесс. Нормальная реакция.

Источник