Есть ли разница между TDD и Test First Development (или Test First Programming)?
Обе идеи звучат очень похоже на меня, но могут быть тонкие различия или одно и то же, объясненные по-разному. Какова связь между TDD и Test First Development/Programming?
8 ответов
Есть разница с точки зрения того, что является движущим фактором.
У вас есть смутное представление о том, как должен выглядеть класс (или система - это, конечно, может происходить в разных масштабах), а затем придумать тесты, которые придают ему реальную форму? Это TDD.
Вы точно знаете, каким должен быть публичный API класса, и просто пишете тесты перед реализацией? Это тестовая разработка.
Мой стиль имеет тенденцию быть смесью двух. Иногда очевидно, каким должен быть API, прежде чем писать какие-либо тесты - в других случаях тестируемость действительно движет дизайном.
Иными словами, TDD начинается с "Какие вопросы я хочу задать?" тогда как не-TDD (будь то тестирование первым или нет) начинается с "Какой ответ я хочу дать?"
Это в основном разные имена, описывающие одно и то же - ну, на самом деле пять имен, так как последний D может обозначать как Дизайн, так и Разработка.
Test First был термином, который первоначально использовался, особенно в контексте экстремального программирования, для цикла test-code-refactor. Позже было предложено название "Разработка через тестирование", которое было быстро принято, чтобы подчеркнуть тот факт, что TFD является - и всегда был - скорее стратегией проектирования, чем стратегией тестирования.
Очевидно, что сегодня некоторые люди имеют разные значения для этих двух терминов, но это не было целью их существования, и я бы не стал полагать, что это общеизвестно (потому что это не так). На самом деле, я бы предпочел, чтобы термин TFD считался устаревшим.
Есть много схожих терминов, таких как программирование в начале теста, разработка вначале теста, разработка через тестирование или даже дизайн через тестирование. Важно уточнить несколько моментов:
1. Тестирование первого программирования (TFP)
Термин "тестирование в первую очередь" - это лучшая практика программирования. Он был вновь введен (если не придуман) Кентом Беком в его книге "Объяснение экстремального программирования": "Написать модульные тесты перед программированием и поддерживать все тесты в рабочем состоянии". Итак, когда мы говорим о программировании на основе тестов, мы говорим о написании автоматических модульных тестов самим разработчиком, который собирается написать код, удовлетворяющий этим тестам. Модульные тесты накапливаются и создают набор автоматических регрессионных тестов, который можно запускать периодически.
2. Разработка через тестирование (TDD)
Разработка через тестирование (TDD) - это название методологии, представленной Кентом Беком в его книге "Разработка через тестирование на примере". Это процесс разработки программного обеспечения, речь идет не только о написании тестов перед кодом. Вся книга пытается объяснить это шаблонами, рабочими процессами, культурой и так далее. Одним из важных аспектов этого является акцент на рефакторинг.
Некоторые люди используют термины "разработка вначале тестирование", "проектирование через тестирование" или "программирование через тестирование" и... Одно можно сказать наверняка: хорошо разработанная методология - это разработка через тестирование, а методика программирования - это программирование на основе тестов. Остальные либо вообще ссылаются на идею написания тестов перед кодом, либо ошибочно ссылаются на разработку через тестирование или программирование на основе тестов.
TDD = TFD + Рефакторинг.
Когда вы делаете TFD, вы применяете некоторый рефакторинг, чтобы сделать код более универсальным и надежным.
Исторически верно: тестовое программирование и разработка через тестирование означают одно и то же с улучшенным именем
В контексте XP (Extreme Programming), который является процессом разработки программного обеспечения, благодаря которому популярное программирование и разработка через тестирование стали популярными, программирование сначала было переименовано в разработку через тестирование, а затем через проектирование, основанное на тестировании, после осознания того, что Написание тестов в первую очередь оказывает чрезвычайно положительное влияние на архитектуру программного обеспечения и дизайн программной системы.
Это влияние на архитектуру и дизайн является следствием более или менее удивительных синонимов:
- Тестируемые
- отсоединенных
- многоразовый
- Независимо развертываемый
- Независимо развивающийся
- Независимо Разумный
Программные объекты могут быть легко использованы повторно, протестированы, развернуты независимо, разработаны независимо или легко обоснованы отдельно, если они не связаны между собой. Написание тестов перед фактической реализацией является практически пуленепробиваемым методом, обеспечивающим непрерывную развязку.
Это влияние на дизайн и архитектуру программного обеспечения стало настолько важным, помимо других положительных эффектов, что создатели посчитали целесообразным переименовать его из Test-First Programming в Test-Driven Development.
Название Test-Driven Development также помогает лучше продвигать метод с точки зрения принятия и правильного понимания, потому что название Test-Driven Development делает упор на целостных аспектах метода, чем Test-First Programming.
Не исторически правильно, но полезно
Хотя исторически это не правильно, я считаю следующее различие очень полезным:
Тестирование в начале программирования...
… Любой метод, в котором тесты для тестируемого кода пишутся перед тестируемым кодом.
Разработка через тестирование…
… Представляет собой специфическое подмножество программ "сначала тестируй", которое следует трем законам разработки, управляемой тестами, как описано Робертом К. Мартином:
- Вы не можете написать производственный код до тех пор, пока не напишете неудачный модульный тест.
- Вы не можете написать больше модульных тестов, чем достаточно для сбоя, а не компиляция не удалась.
- Вы не можете написать больше производственного кода, чем достаточно для прохождения в настоящее время неудачного модульного теста. - Роберт К. Мартин, Три закона развития, управляемого тестами
Следуя этим трем правилам, вы попадаете в цикл Red-Green-Refactor. 1. Вы пишете провальный тест. 2. Вы делаете это пройти. 3. Теперь, когда оно прошло, вы можете беспощадно провести рефакторинг, прежде чем писать следующий неудачный тест.
Обратите внимание, что рефакторинг безопасно требует испытаний. Рефакторинг означает изменение структуры исходного кода без изменения существенного поведения. Но откуда мы знаем, что мы случайно не изменили существенное поведение? Что определяет существенное поведение? Это одна из многих вещей, для которых полезны тесты.
Кстати, если ваши тесты мешают рефакторингу, ваши тесты слишком низкоуровневые, слишком тесно связаны, и, возможно, вы использовали слишком много насмешек.
Другие интересные переименования в Extreme Programming
- Непрерывная интеграция -> Непрерывная доставка -> Непрерывное развертывание; Строго говоря, они означают разные вещи, однако, в духе XP, это означало "Непрерывное развертывание с самого начала", и когда люди запрыгнули на подножку, стало понятно, что интеграция воспринималась слишком буквально, и люди останавливались до того, как это сделали.
- Непрерывный рефакторинг -> Непрерывное улучшение дизайна; Рефакторинг не является средством для достижения цели, но преследует более высокую цель.
- 40 часов в неделю -> Sustainable Pace (Городская легенда: это переименование произошло после протестов французских разработчиков программного обеспечения.)
В тесте, управляемом разработкой: в качестве примера, автор, Кент Бек, четко заявляет, что правило "сначала тест" (TF) является правилом. Так что TF - это принцип, который управляет TDD. Более поздний процесс.
TDD (разработка через тестирование) - это тестирование в первую очередь разработка / программирование, хотя я видел и слышал, что TDD означает создание постоянных, повторяемых модульных тестов (даже после кода), но на самом деле это означает, что тесты пишутся до кода, который они тестируют.
Они точно такие же. Обе ссылки сначала пишут тесты, затем пишут код, который пройдет тест