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

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

---

практик в д о статочном объеме д аже в со стоянии стресса. На рис. П1.5
показан пример системы практик, которая привод ит к нед о статочному
тестированию.
Когд а время начинает под жимать, вы снижаете интенсивно сть
тестирования, что привод ит к увеличению количества ошибок, что, в
свою очеред ь, привод ит к еще большему нед о статку времени. Со
временем на сцене появляется некоторое внешнее д ействие (например,
нед о статок д енег), которое заставляет вас завершить работу над
проектом, несмотря ни на что.
Рис. П1.5.
Нед о статок времени д ля тестирования привод ит к
общему нед о статку времени
Если вы имеете д ело с системой, которая вед ет себя не так, как вам
того хотело сь бы, у вас есть несколько вариантов исправить ситуацию:
• Сформируйте цикл положительной обратной связи в обратном
направлении. Если у вас цикл межд у тестами и уверенно стью и тесты
все время терпят неуд ачу, снижая тем самым уверенно сть, тогд а вы
сможете сд елать больше успешных тестов, повысив тем самым
уверенно сть в вашей спо собно сти увеличить количество работающих
тестов.
• Сформируйте цикл отрицательной обратной связи, который
позволит вам контролировать д ействие, интенсивно сть которого стала
слишком большой.
• Созд айте или разорвите соед инения, чтобы устранить циклы, не
являющиеся полезными.

---

Приложение II 
Фибоначчи 
В ответ на про сьбу од ного из моих рецензентов я включил в книгу
описание 
разработки 
функции 
вычисления 
по след овательно сти
Фибоначчи в стиле TDD. Некоторые утвержд ают, что именно этот
пример раскрыл им глаза на механику работы TDD. Од нако этот пример
очень короток, к тому же в нем не используются многие важные приемы,
применяемые в рамках TDD. По этой причине его невозможно
использовать в качестве замены примеров, рассмотренных ранее в
д анной книге. Если, ознакомившись с рассмотренными ранее примерами,
вы д о сих пор не можете понять, как о существляется разработка в стиле
TDD, ознакомьтесь с д анным материалом, возможно, он поможет вам
прояснить ситуацию.
Первый тест показывает, что fib(0) = 0. Реализация возвращает
константу.
public void testFibonacci() {
assertEquals(0, fib(0));
}
int fib(int n) {
return 0;
}
(Я использую класс TestCase как вместилище код а, так как мы
разрабатываем всего од ну функцию.)
Второй тест показывает, что fib(1) = 1.
public void testFibonacci() {
assertEquals(0, fib(0));
assertEquals(1, fib(1));
}
Я про сто д обавил еще од ин оператор assert() в тот же самый
тестовый метод , так как не вижу о собого смысла созд авать новый

---

метод с именем testFibonacciOfOneIsOne.
Чтобы заставить тест работать, можно во спользоваться од ним из
нескольких метод ов. Я решаю использовать значение 0 как специальный
случай:
int fib(int n) {
if