Исторически верно: тестовое программирование и разработка через тестирование означают одно и то же с улучшенным именем
В контексте XP (Extreme Programming), который является процессом разработки программного обеспечения, благодаря которому популярное программирование и разработка через тестирование стали популярными, тестирование сначала было переименовано в разработку через тестирование, а затем через проектирование через тестирование. осознание того, что написание тестов в первую очередь оказывает огромное положительное влияние на архитектуру программного обеспечения и проектирование программной системы.
Это влияние на архитектуру и дизайн является следствием более или менее удивительных синонимов:
- Testable
- отсоединенных
- Многоразовые
- Возможность самостоятельного развертывания
- Самостоятельно развивающийся
- Независимо Разумный
Программные объекты могут быть легко повторно использованы, протестированы, развернуты независимо, разработаны независимо или легко обоснованы отдельно, если они не связаны между собой. Написание тестов перед фактической реализацией является практически пуленепробиваемым методом, обеспечивающим непрерывную развязку.
Это влияние на дизайн и архитектуру программного обеспечения стало настолько важным, помимо других положительных эффектов, что создатели посчитали целесообразным переименовать его из Test-First Programming в Test-Driven Development.
Название Test-Driven Development также помогает лучше продвигать метод с точки зрения принятия и правильного понимания, потому что название Test-Driven Development делает упор на целостных аспектах метода, чем Test-First Programming.
Исторически не верно, но полезно
Хотя исторически это не правильно, я считаю следующее различие очень полезным:
Тестирование в начале программирования ...
… - это любой метод, в котором тесты для тестируемого кода пишутся перед тестируемым кодом.
Разработка через тестирование…
… является специфическим подмножеством тестового программирования, которое следует 3 законам разработки через тестирование, как описано Робертом К. Мартином:
- Вы не можете написать производственный код, пока не напишете провальный модульный тест.
- Вы не можете написать больше модульных тестов, чем достаточно для сбоя, и отказ от компиляции завершается неудачей.
- Вы не можете написать больше производственного кода, чем достаточно для прохождения в настоящее время неудачного модульного теста.
- Роберт К. Мартин, Три закона развития, управляемого тестами
Следуя этим трем правилам, вы попадаете в так называемый цикл Red-Green-Refactor.
1. Вы пишете провальный тест.
2. Вы делаете это пройти.
3. Теперь, когда оно прошло, вы можете беспощадно провести рефакторинг, прежде чем писать следующий неудачный тест.
Обратите внимание: для безопасного рефакторинга требуются тесты. Рефакторинг означает изменение структуры исходного кода без изменения существенного поведения. Но откуда мы знаем, что мы случайно не изменили существенное поведение? Что определяет значительное поведение? Это одна из многих вещей, для которых полезны тесты.
Кстати, если ваши тесты мешают рефакторингу, ваши тесты слишком низкоуровневые, слишком тесно связаны, и, возможно, вы использовали слишком много насмешек.
Другие интересные переименования в Extreme Programming
- Непрерывная интеграция -> Непрерывная доставка -> Непрерывное развертывание; Строго говоря, они означают разные вещи, однако, в духе XP, это означало «Непрерывное развертывание с самого начала», и когда люди запрыгнули на подножку, было понято, что интеграция была воспринята слишком буквально, и люди остановились, прежде чем они сделали. *
- Непрерывный рефакторинг -> Постоянное улучшение дизайна; Рефакторинг не является средством для достижения цели, но преследует более высокую цель.
- 40 часов в неделю -> Sustainable Pace (Городская легенда: это переименование произошло после протестов французских разработчиков программного обеспечения.)