Поработав с юнит тестами и ребятами, которые учились этому интересному делу я заметил несколько ступенек развития. Перепрыгивать ступеньки не стоит - ничего из этого хорошего не получится. Особенно актуально эта информация для менеджеров, которые хотят на своих проектах видеть TDD - сразу вы его не увидите, как ни крути. Все должно быть естественно и последовательно.
1-я ступень. Тесты не писались и не пишутся. Код разрабатывается по классике: кодим, тестим, дебажим, снова тестим - все ручками. Лечение: начать писать хоть какие-то тесты, в любое время - как удобно, тем самым часть мануальной работы переложить на компьютер. Качество тестов не так интересует, как количество.
2-я ступень. Тесты пишутся после того, как написан код. Возможно этого кто-то требует сверху, возможно появилась заинтересованность в автотестах. Тесты обычно интергационные, потому как протестировать сильно связанную систему оказыватся не так просто. Лечение: пытаться тестировать не в конце итерации (1-2 недели), а хотя-бы в конце дня, постепенно сокращая по времени итерацию Код-Тест.
3-я ступень. Тесты пишутся параллельно с кодом, но с небольшой задержкой. Обычно они более-менее юнит, а архитектура тестируемого кода, соответственно, более-менее модульная. Дебагом пользуемся, но не зависая надолго. Обычно уже тут специалист test infected и слабо представляет разработку без тестов. Лечение: пробовать TDD.
4-я ступень. Разработка управляемая тестированием, то есть TDD. Первые шаги, основа есть. Все немного максималистично - coverage 100%, никакого debug, только TDD всегда и везде! Лечение: пообщаться (поработать в паре) с такими же TDD практиками, пробовать всевозможные unit testing фреймворки, BDD, помагать любопытным коллегам с вопросами о TDD .
5-я ступень. TDD ретранслятор. Либо XP коуч в проекте, либо тренер-консультант, либо просто на конференциях выступает (или блог интересный ведет). Обычно с TDD все уже достаточно хорошо, как в новых проектах так и legacy. Инструмент используется эффективно в комбинации с другими инструментами или не используется. Лечение: Неизвестно.
6-я ступень. Ваши варианты?
1-я ступень. Тесты не писались и не пишутся. Код разрабатывается по классике: кодим, тестим, дебажим, снова тестим - все ручками. Лечение: начать писать хоть какие-то тесты, в любое время - как удобно, тем самым часть мануальной работы переложить на компьютер. Качество тестов не так интересует, как количество.
2-я ступень. Тесты пишутся после того, как написан код. Возможно этого кто-то требует сверху, возможно появилась заинтересованность в автотестах. Тесты обычно интергационные, потому как протестировать сильно связанную систему оказыватся не так просто. Лечение: пытаться тестировать не в конце итерации (1-2 недели), а хотя-бы в конце дня, постепенно сокращая по времени итерацию Код-Тест.
3-я ступень. Тесты пишутся параллельно с кодом, но с небольшой задержкой. Обычно они более-менее юнит, а архитектура тестируемого кода, соответственно, более-менее модульная. Дебагом пользуемся, но не зависая надолго. Обычно уже тут специалист test infected и слабо представляет разработку без тестов. Лечение: пробовать TDD.
4-я ступень. Разработка управляемая тестированием, то есть TDD. Первые шаги, основа есть. Все немного максималистично - coverage 100%, никакого debug, только TDD всегда и везде! Лечение: пообщаться (поработать в паре) с такими же TDD практиками, пробовать всевозможные unit testing фреймворки, BDD, помагать любопытным коллегам с вопросами о TDD .
5-я ступень. TDD ретранслятор. Либо XP коуч в проекте, либо тренер-консультант, либо просто на конференциях выступает (или блог интересный ведет). Обычно с TDD все уже достаточно хорошо, как в новых проектах так и legacy. Инструмент используется эффективно в комбинации с другими инструментами или не используется. Лечение: Неизвестно.
6-я ступень. Ваши варианты?
Сообщения
А есть, как всегда, режим "по желанию". Иногда вовсе не хочется тесты писать, а иногда аж руки чешутся - и куда это меня зведёт?
ОтветитьУдалитьТогда парное программирование когда не хочется ТДД :)
УдалитьА ещё лучше и то и то в комплексе
Леша привет, пробуй тестировать чаще через немогу :)
УдалитьОни все в комплексе в XP засандалили - коуча, парное программирование, тдд, рефакторинги, СI... не просто так - оно друг друга поддерживает.
Удалитьна текущий момент я по этой градации на пути от 3-й к 4-й ступени :)
ОтветитьУдалитьВ своей работе с кодом, программист должен руководствоваться девизом "Не верю!".
ОтветитьУдалитьЧтобы TDD принесло свои плоды, программист должен пройти три ступени:
1) трудное надо сделать привычным,
2) привычное - легким,
3) легкое - приятным.
Как театр начинается с вешалки, так и разработка кода должна начинаться с тестирования.
В общем, TDD - это программирование по Станиславскому. :)
http://www.zitata.eu/stanislawsky.shtml
Точно, Олег!
ОтветитьУдалитьА вообще, просветленный этот дядька - Станиславский.
1) трудное надо сделать привычным = надо просто писать юнит тесты, не важно какие
2) привычное - легким = поиск ответа на вопрос, как писать Юнит тесты проще, качественнее; где-то тут пробовать ТДД.
3) легкое - приятным = смотреть в оба, наблюдать за своим ТДД; понять, что ошибаюсь чаще чем кажется (отсюда то самое "не верю!"), понять, что наконец-то могу делать управляемый рефакторинг; привыкнуть, что все под контролем...