Поработав с юнит тестами и ребятами, которые учились этому интересному делу я заметил несколько ступенек развития. Перепрыгивать ступеньки не стоит - ничего из этого хорошего не получится. Особенно актуально эта информация для менеджеров, которые хотят на своих проектах видеть 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-я ступень. Ваши варианты?