Как работает TDD

[vak]

TDD это относительно новая методика разработки программ, получившая распространение в последние десять-пятнадцать лет. Вот презентация, иллюстрирующая метод на примере решения учебной задачи: вычисления счёта игры в боулинг. Задача несложная, но при этом нетривиальная.

Bowling Game Kata.ppt

Краткое изложение подсчета очков для американского боулинга:

• Игра состоит из десяти «фреймов».
• В каждом фрейме игрок может делает по два броска шара, с целью сбить десять кеглей.
• Если с двух бросков не удалось сбить все кегли, счет за этот фрейм равен общему количеству кеглей, сбитых за две попытки.
• Если в двух бросках сбиты все кегли, это называется «спэр», и счет за фрейм составляет десять плюс количество кеглей, сбитых при следующем броске (на следующем ходу).
• Если при первом броске в фрейме сбиты все кегли, это называется «страйк». Ход игрока окончен, и его счет за фрейм - десять плюс сумма кеглей, сбитых в его следующих двух бросках.
• Если игрок выбивает спэр или страйк в последнем (десятом) фрейме, он может бросить еще один или два бонусных шара соответственно. Эти бонусные броски выполняются как часть одного хода. Если бонусные броски сбивают все кегли, процесс не повторяется: бонусные броски используются только для подсчета очков в последнем фрейме.
• Счет игры - это сумма очков за все фреймы.

Задача написать класс “Game”, у которого есть два метода:

• void roll(int pins); -- вызывается, когда игрок бросает шар. Аргумент задаёт количество сбитых кеглей.
• int score(); -- вызывается в конце игры и возвращает общий счёт.

Метод TDD можно уместить в три принципа.

1. Вы не имеете права написать ни строчки кода, пока вы не напишете тест (который не проходит).
2. Вы не имеете права в тесте написать больше, чем нужно, чтобы тест не прошёл. Ошибка компиляции тоже засчитывается за непрошедший тест, скажем, отсутствие нужного класса или метода.
3. Вы не имеете права писать больше кода, чем требуется, чтобы сбоящий тест прошёл.

Разработка программы идёт по циклу в три шага: красный/зелёный/рефактор.

• Добавляем новый тест. Запускаем все тесты, убеждаемся, что новый тест не проходит. Это красная фаза.
• Пишем код, чтобы тест срабатывал как положено. Главное функциональность, элегантность пока не волнует. Опять запускаем все тесты: проверяем, что все они проходят. Это зелёная фаза.
• Функциональность достигнута, теперь переделываем код, чтобы добиться внутренней красоты и элегантности. Меняем представление данных, разбиение по методам, классам и модулям. Снова запускаем все тесты: всё должно проходить.
• Повторяем весь цикл сначала.

Заметьте: добавлять новую функциональность можно только в красной фазе, в ответ на непроходящий тест. Улучшать и изменять код можно только в зелёной фазе. Тесты помогут сохранять уверенность, что вы ничего не сломали. Третий шаг, рефакторинг - самый трудоёмкий. Именно здесь вы фактически строите, достраиваете и перестраиваете архитектуру вашей системы.

На слайдах по вышеупомянутой ссылке можно видеть, как разработка всей программы для боулинга проходит всего за пять тестов.

Comments

[vit_r]

Это методика для выполнения университетских упражнений.

В реальных задачах просто невозможно таскать весь объём и не запутаться.

[rdia.livejournal.com]

Адепты тестов всюду и везде не учитывают, что тесты - это тоже код со всеми сопутствующими минусами.

[vit_r]

В этом смысле, да. Проще написать альтернативное решение задачи и сравнивать результаты. Как, собственно, делают в mission critical системах. (Хотя, есть методы и поэффективнее.)

Но, если писать тесты, кода полчится больше. А писать код интереснее, чем думать над решением.

[permeakra]

Как тестировать тесты?

[vak]

Хорошая отговорка их не писать. :)

Вопрос на самом деле серьёзный, и стоит гораздо шире. Правильные ли юнит-тесты? На самом деле: делает ли программа то, что нужно?

Юнит-тесты фактически являются спецификацией нижнего уровня. У этой спецификации есть риск не соответствовать бизнес-требованиям, то есть спецификации верхнего уровня. Эта проблема решается другим методом, не связанным с TDD. Не суть, разрабатываете ли вы программу посредством TDD или по другому, с юнит-тестами или без, вам придётся как-то обеспечить соответствие требованиям.

Тут вступают в дело другие методики. Самая известная - это acceptance-тесты. Их разрабатывают архитекторы или бизнес-аналитики, другая
команда, отдельная от программистов.

К примеру, когда я работал в MIPS, у нас был программный пакет под названием Architectural Verification Suite. Это несколько тысяч тестов, каждый от нескольких тысяч до миллионов строк ассемблера. Тесты разрабатывались архитектурной командой и проверяли поведение каждой машинной команды и каждого бита каждого регистра на соответствие спецификации MIPS, во всех возможных ситуациях. Для других команд, разрабатывавших конкретный процессор (или симулятор, как я), эти тесты служили "критерием истины".

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

[brmail]

мои 20+ лет практики подсказывают, что сами по себе юнит тесты в реальной жизни пользы не принесут. Те изначально, может и неплохо их иметь, но в процессе дополнения системы новым кодом они устаревают. Ломается система не потому, что ее сейчас неправильно написали, а потому что в результате изменений что-то не то стало приходить туда, где такого не ждали. И нередко это "не то" настолько специфично, что для такого изначально эти самые юнит тесты и не приспособлены. А вот написали систему несколько лет назад, и эти годы она меняется, растет и фиг кто эти самые юнит тесты будет дополнять, если не меняет непосредственно объект, а оно хлоп и внезапно работает не так как ожидалось. И хорошо, если вернет ошибку, а не молча ее проглотит и пойдет исполнять код дальше.

[vak]

Если со временем требования к системе меняются, надо соответствующим образом менять и юнит-тесты. Собственно, юнит-тесты и есть формализованная спецификация системы. Если забывать её обновлять, то да, будет бардак.

По моему опыту, правильный набор юнит-тестов может оказаться ценнее собственно кода системы. Если система пришла в состояние неисправимого бардака (а я видел реальный случай), её можно выкинуть и нанять команду написать всё с нуля. Но - только если у вас есть юнит тесты с хорошим покрытием. Тогда работа делается за предсказуемое время с гарантированным результатом.

Если же у вас на руках глючная система без тестов, тут дело табак. То ли чинить - неизвестно, столько времени уйдёт, то ли выкинуть и переписать - опять сроки непонятные.

[rdia.livejournal.com]

Фактически вам нужны просто требования, а не тесты. Но в случае бардака вы можете понять какие были требования из кода, тестов и описания системы.

[permeakra]

>Вопрос на самом деле серьёзный, и стоит гораздо шире.

Нет, в данном случае он был поставлен достаточно узко - как тестировать тесты. Подразумевается, что объем осмысленного кода в тестах оказывается как минимум таким же, если не больше, чем в основном коде. К примеру, решение квадратного уравнения можно уложить в одну строчку, но существенно различных случаев, которые надо тестировать - минимум три при наивном подходе и минимум шесть при чуть менее наивном.

Ваш пост на этот вопрос не отвечает никак =).

[vak]

Узко поставленный вопрос не так узок, как кажется. Начнём с выяснения: разделяете ли вы юнит-тесты, code coverage тесты и acceptance тесты? У всех них разная методика "тестирования тестов".

И всё это уводит в сторону от темы TDD, заявленной в этом посте. TDD это про разработку, не про тестирование.

[permeakra]

>Узко поставленный вопрос не так узок, как кажется.

Как любой заслуживающий постановки узкий вопрос, это само собой. Но тем не менее.

>acceptance тесты

Acceptance, Regression и Load testing пока оставим за кадром, разберемся пока с тем, что работает уровнем ниже.

[vak]

> Ваш пост на этот вопрос не отвечает никак =).

TDD не отвечает на вопрос _тестирования_. TDD организует процесс _разработки_ эффективным образом. Тесты образуются в качестве полезного побочного продукта.

К теме квадратного уравнения. Скажем, есть требование: появление на входе NaN должно выдавать NaN в качестве результата. Добавляем простой юнит-тест. Как проверить, правильный ли этот тест? Прочитать глазами тест и прочитать требования.

[permeakra]

TDD использует тесты как способ записи локальной спецификации. Это, безусловно, единственно корректный подход во всяком шроте типа питона и JS. Но понятие сигнатуры (типа) функции придумано очень давно, и при нормальной политике именования и минимальной сопутствующей документации этого достаточно.

Вот с тем же успехом можно записать требования к новому куску кода и сличать глазами то, что делает кусок кода с тем, что записано в спецификации. Так зачем нужны юнит тесты? Особенно учитывая, что качество кода с покрытием юнит-тестами не очень-то коррелирует.

[rdia.livejournal.com]

+ 100% покрытие кода функции юнит-тестами далеко не означает полное тестирование этой функции из-за взаимовлияния разных условных выражений.

[vak]

Есть тесты для покрытия кода (обычно юнит тесты), есть тесты для покрытия функциональности (обычно acceptance тесты). Но всё это ортогонально TDD.

[vak]

Сигнатура даёт только общее впечатление о функции. Даже для "чистых" функций это не работает. К примеру, "double atof (const char* str);" - много ли мы узнаём из сигнатуры? Строка каким-то образом превращается в вещественное число. Мы можем только догадываться, как число записывается. Что происходит, если в строке мусор? Будет ли результатом NaN или исключение? Может ли получиться денормализованное число? Куча вопросов, и ответом могут быть только юнит-тесты.

Спецификации сами по себе вещь довольно бесполезная для разработки. Не будете же вы после каждого коммита вручную перечитывать все спецификации и сличать с исходниками. Запуск же юнит-тестов через несколько секунд даст вам вопрос, не сломалось ли что-нибудь.

Качество кода зависит не от тестов, верно. Оно зависит от код ревью. Это отдельная тема, не связанная ни с TDD, ни с тестированием.

[permeakra]

Вот это вот
>при нормальной политике именования и минимальной сопутствующей документации
мы специально проигнорировали?

>Куча вопросов, и ответом могут быть только юнит-тесты.
Нет. Юнит-тесты вообще очень мало говорят об ожидаемом поведении кода, они лишь требуют определенного выхлопа при заданном входе в заданном окружении. Всегда остается вопрос, как код должен себя вести при других входах и в другом окружении. Можно, конечно, пойти по пути наименьшего сопротивления и везде таскать свою среду - но это так себе решение в долгосрочной перспективе.

[ircicq]

Расчёт, что в скором будущем реализацию будет писать AI
Программисту останутся только тесты

[vak]

Хорошо бы, но вряд ли. Всё таки инженерное дело достаточно креативное занятие, тут неестественный интеллект не справится.

[rdia.livejournal.com]

> Программисту останутся только тесты

Не тесты, а спецификации. Но формальная спецификация для программы на низкоуровневом языке - это программа на высокоуровневом. И дальше возникает вопрос - а почему не написать компилятор для этого высокоуровневого?

Вот так примерно появляются gprolog, ghc, функция compile в Wolfram Mathematica и т.д.

[fizzik]

То есть предлагается сначала писать "как нибудь", лишь бы заработало, а потом уже все переделывать, чтобы код был логичным, "красивым", использовал ресурысы эффективно и т.п.
Как-то сомнительно. Почему сразу не писать нормально?

[vak]

Потому что так не бывает. Москва не сразу строилась. Нельзя вот так сразу взять и слепить код, который будет красивым, эффективным, и делать то что нужно. Реальная разработка это долгий процесс движения к идеалу.

[fizzik]

Ну ясное дело, что разработка - процесс итерационный.
Но я все же думаю, что "красиво" должно быть с самого начала. Понятно, что на следующих итерациях с большой вероятностью придется многое переделывать, но "красивый" код и переделывать проще, меньше шансов насажать ошибок.

[vak]

"Красиво" становится после третьего шага, рефакторинга.

[x86128]

Ну вот и чем процесс программирования, при таком подходе отличается от работы скульптора или художника? Постепенно/итеративно из грубых форм(цветовых пятен) рождается шедевр - красивая программа. :)

От большинства ораторов ускользает главный посыл TDD - это процесс ваяния ПО, а не процесс написания формальной спецификации или чего либо еще - процесс который приводит к красивому ПО.

Насколько я понял это впервые появилось при разработке Ruby. Смотреть в код языка Crystal, который продолжает идеи руби но с выводом типов и компиляциией ллвм в машинный код, очень приятно - красиво и понятно всё.

[vak]

Есть общее с художником, да. Програмирование несколько более технологично, правда, чем художественное искусство, но вкус и чувство красоты тут играют не меньшую роль.

TDD вроде изобрёл Кент Бек, и там была Java, судя по его книжке. Но это не так важно, какой язык. Методика работает с любым языком программирования.