Экстремальное программирование. Разработка через тестирование

Сколько должно быть тестов?
Насколько емкой д олжна быть обратная связь? Рассмотрим про стую
зад ачу: д ано три целых числа, обозначающих д лины сторон
треугольника. Метод д олжен возвращать:
• 1 – в случае, если треугольник равно сторонний;
• 2 – в случае, если треугольник равнобед ренный;
• 3 – в случае, если треугольник не равно сторонний и не
равнобед ренный.
Если д лины сторон зад аны некорректно (невозможно по строить
треугольник 
со 
сторонами 
зад анной 
д лины), 
метод
д олжен
генерировать исключение.
Вперед ! Попробуйте решить зад ачу (мое решение, написанное на
языке Smalltalk, привед ено в конце д анного под разд ела).
Это отчасти напоминает игру «Угад ай мелод ию» («Я могу
закод ировать зад ачу за четыре теста!» – «А я – за три!» – «О’кей
попробуйте».) Для решения зад ачи я написал шесть тестов, а Боб Бинд ер
в своей книге 
Testing Object-Oriented Systems
[29]
(«Тестирование
объектно-ориентированных систем») д ля этой же самой зад ачи написал
65 тестов. Сколько на самом д еле нужно тестов? Вы д олжны решить это
сами, исход я из собственного опыта и рассужд ений.
Когд а я д умаю о необход имом количестве тестов, я пытаюсь
оценить приемлемое 
среднее время между сбоями
(MTBF, Mean Time
Between Failures). Например, в языке Smalltalk целые числа вед ут себя как

---

целые числа, а не как 32-битные значения. Иными словами, максимально
возможное значение целого числа ограничивается не трид цатью д вумя
битами, а объемом памяти. Это означает, что вы можете обойтись без
тестирования MAXINT. Безусловно, опред еленный пред ел существует,
вед ь теоретически можно созд ать целое число, д ля хранения которого
не хватит имеющейся памяти. Но д олжен ли я тратить время на
написание и реализацию теста, пытающего ся заполнить память
невероятно огромным целым числом? Как это повлияет на MTBF моей
программы? Если я в обозримом буд ущем не собираюсь иметь д ело с
треугольниками, размер сторон которых измеряется такими числами,
значит, моя программа не станет существенно менее над ежной, если я не
реализую такой тест.
Имеет ли смысл писать тот или иной тест? Это зависит от того,
насколько аккуратно вы оцените MTBF. Если обстоятельства требуют,
чтобы вы увеличили MTBF от 10 лет д о 100 лет, значит, имеет смысл
уд елить время д ля разработки самых маловероятных и чрезвычайно
ред ко возникающих ситуаций (если, конечно, вы не можете каким-либо
иным образом д оказать, что под обные ситуации никогд а не могут
возникнуть).
Взгляд на тестирование в рамках TDD прагматичен. В TDD тесты
являются сред ством д о стижения цели. Целью является код , в
корректно сти которого мы в д о статочной степени уверены. Если знание
о собенно стей реализации без какого-либо теста д ает нам уверенно сть в
том, что код работает правильно, мы не буд ем писать тест.
Тестирование черного ящика (когд а мы намеренно игнорируем
реализацию) облад ает ряд ом преимуществ. Если мы игнорируем код , мы
наблюд аем д ругую систему ценно стей: тесты сами по себе
пред ставляют д ля нас ценно сть. В некоторых ситуациях это вполне
оправд анный под ход , од нако он отличается от TDD.