Разработку через тестирование можно описать тремя простыми правилами.
• Не пишите готовый код до того, как напишете тест, который не получится пройти из-за нехватки этого кода.
• Не пишите тестов больше, чем это необходимо для неудачи, – сбой при компиляции также считается неудачей.
• Не пишите готового кода больше, чем достаточно для прохождения теста, который был провален до этого.
Мы, программисты, просто не знаем, что сколько времени займет. Так происходит не потому, что мы тормозим или ленивы, а потому, что просто-напросто невозможно узнать, насколько сложно будет выполнить задание, до тех пор пока мы не принялись за него и не завершили
Разработчики не должны спрашивать разрешения на написание тестов. У них не должно быть отдельных заданий для проведения модульных тестов и рефакторинга. У них не должно быть отдельных заданий для реализации какого-либо функционала. Такая техническая работа должна быть учтена при разработке каждой функции. Она обязательна.
Клиенты имеют право на отслеживание хода работ, назначение необходимых тестов, получение рабочего и многократно протестированного программного обеспечения.
Эффективность программного обеспечения измеряется в том числе и тем, насколько безболезненно в него можно внести какие-либо изменения. Клиенты, пользователи и руководители ожидают, что программное обеспечение будет можно легко изменить и что стоимость таких изменений будет соизмеримой и как можно ниже.
трехвариантный анализ. Такие оценки включают в себя три положения: лучший случай, допустимый случай и худший случай. С помощью такого анализа можно предречь исход с различной вероятностью. Худший случай – это когда мы уверены в сроках на 95 %. Допустимый – на 50 %, а лучший – на 5 %.