TDD это относительно новая методика разработки программ, получившая распространение в последние десять-пятнадцать лет. Вот презентация, иллюстрирующая метод на примере решения учебной задачи: вычисления счёта игры в боулинг. Задача несложная, но при этом нетривиальная.
Bowling Game Kata.ppt Краткое изложение подсчета очков для американского боулинга:
- Игра состоит из десяти «фреймов».
- В каждом фрейме игрок может делает по два броска шара, с целью сбить десять кеглей.
- Если с двух бросков не удалось сбить все кегли, счет за этот фрейм равен общему количеству кеглей, сбитых за две попытки.
- Если в двух бросках сбиты все кегли, это называется «спэр», и счет за фрейм составляет десять плюс количество кеглей, сбитых при следующем броске (на следующем ходу).
- Если при первом броске в фрейме сбиты все кегли, это называется «страйк». Ход игрока окончен, и его счет за фрейм - десять плюс сумма кеглей, сбитых в его следующих двух бросках.
- Если игрок выбивает спэр или страйк в последнем (десятом) фрейме, он может бросить еще один или два бонусных шара соответственно. Эти бонусные броски выполняются как часть одного хода. Если бонусные броски сбивают все кегли, процесс не повторяется: бонусные броски используются только для подсчета очков в последнем фрейме.
- Счет игры - это сумма очков за все фреймы.
Задача написать класс “Game”, у которого есть два метода:
- void roll(int pins); -- вызывается, когда игрок бросает шар. Аргумент задаёт количество сбитых кеглей.
- int score(); -- вызывается в конце игры и возвращает общий счёт.
Метод TDD можно уместить в три принципа.
- Вы не имеете права написать ни строчки кода, пока вы не напишете тест (который не проходит).
- Вы не имеете права в тесте написать больше, чем нужно, чтобы тест не прошёл. Ошибка компиляции тоже засчитывается за непрошедший тест, скажем, отсутствие нужного класса или метода.
- Вы не имеете права писать больше кода, чем требуется, чтобы сбоящий тест прошёл.
Разработка программы идёт по циклу в три шага: красный/зелёный/рефактор.
- Добавляем новый тест. Запускаем все тесты, убеждаемся, что новый тест не проходит. Это красная фаза.
- Пишем код, чтобы тест срабатывал как положено. Главное функциональность, элегантность пока не волнует. Опять запускаем все тесты: проверяем, что все они проходят. Это зелёная фаза.
- Функциональность достигнута, теперь переделываем код, чтобы добиться внутренней красоты и элегантности. Меняем представление данных, разбиение по методам, классам и модулям. Снова запускаем все тесты: всё должно проходить.
- Повторяем весь цикл сначала.
Заметьте:
добавлять новую функциональность можно только в красной фазе, в ответ на непроходящий тест.
Улучшать и изменять код можно только в зелёной фазе. Тесты помогут сохранять уверенность, что вы ничего не сломали. Третий шаг, рефакторинг - самый трудоёмкий. Именно здесь вы фактически строите, достраиваете и перестраиваете архитектуру вашей системы.
На слайдах по вышеупомянутой ссылке можно видеть, как разработка всей программы для боулинга проходит всего за пять тестов.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
