Вы здесь: Home > Правила XP > Unit Test-ы
Что здесь происходит
Правила XP
   Соглашение о кодировании
   Коллективное владение кодом
   Конституция разработки ПО
   CRC Сессия
   Заказчик
   Выбирайте самое простое решение
   Функциональные тесты
   Частая интеграция
   Планирование Итерации
   Итерации
   Меняйтесь задачами
   Оставляйте оптимизацию на потом
   Парное программирование
   Безжалостно Рефакторить!
   План Релиза
   Частые Релизы
   Пробное решение
   Собрание стоя
   Метафора Системы
   Unit Test-ы
   User Story
   Скорость проекта
   Когда обнаружена ошибка
   Вам это не понадобится
Статьи по XP
Книги по XP
Ссылки по XP
Обсудить
Написать нам

Unit Test-ы

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

Хитростью здесь является то, что тест для класса должен быть написан раньше самого класса. Это значит, что как только вы выпустите первый работающий результат, он будет поддерживаться системой тестирования. Для проведения тестов пишется специальная система тестирования со своим интерфейсом.

Unit тест для класса хранится в общем репозитории вместе с кодом класса. Никакой код не может быть выпущен без Unit теста. Перед отдачей кода разработчик должен удостовериться что все тесты проходят без ошибок. Никто не может отдать код если все не прошли 100%. Другими словами поскольку до ваших изменений все тесты проходили, то если вы имеете ошибки, то это результат ваших изменений. Вам и исправлять. Иногда бывает неправильным или неполным код теста. В таком случае надо исправлять его.

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

Unit тесты позволяют осуществить коллективное владение кодом. Они позволяют относительно легко пересматривать плохой код. Также Unit тесты позволяют в любой момент иметь стабильно работающую систему.

Наш опыт.

Сложно начинать писать UnitTest-ы когда уже есть система на 400000 строк. Но можно. Так что пишем. Правило такое - если меняешь код, для которого нет UnitTest-а - напиши сначала тест. Для нового кода все делается по правилам.

Как результат мы имеем заметно более качественный код. Цикл стабилизации системы перед выпуском сократился с полутора месяцев до двух-трех недель. Это при том что Unit тестами покрыто менее половины системы.

Наличие UnitTest-ов позволяет рефакторить систему. Также само написание теста обычно ведет к тому, что структура обьеков становится проще. Часто сначал приходится тестировать всю подсистему, поскольку невозможно выделить один обьект из-за запутанных взаимосвязей. Потихоньку клубок распутывается и все становится ясно и красиво.