Если нельзя, но очень хочется, то нужно обязательно и ничего в мире не стоит того, чтобы делать из этого проблему!


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

вторник, 21 августа 2012 г.

Когда стоит начинать ТДДить?

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

7 комментариев:

  1. А есть, как всегда, режим "по желанию". Иногда вовсе не хочется тесты писать, а иногда аж руки чешутся - и куда это меня зведёт?

    ОтветитьУдалить
    Ответы
    1. Тогда парное программирование когда не хочется ТДД :)
      А ещё лучше и то и то в комплексе

      Удалить
    2. Леша привет, пробуй тестировать чаще через немогу :)

      Удалить
    3. Они все в комплексе в XP засандалили - коуча, парное программирование, тдд, рефакторинги, СI... не просто так - оно друг друга поддерживает.

      Удалить
  2. на текущий момент я по этой градации на пути от 3-й к 4-й ступени :)

    ОтветитьУдалить
  3. В своей работе с кодом, программист должен руководствоваться девизом "Не верю!".
    Чтобы TDD принесло свои плоды, программист должен пройти три ступени:
    1) трудное надо сделать привычным,
    2) привычное - легким,
    3) легкое - приятным.

    Как театр начинается с вешалки, так и разработка кода должна начинаться с тестирования.

    В общем, TDD - это программирование по Станиславскому. :)
    http://www.zitata.eu/stanislawsky.shtml

    ОтветитьУдалить
  4. Точно, Олег!
    А вообще, просветленный этот дядька - Станиславский.

    1) трудное надо сделать привычным = надо просто писать юнит тесты, не важно какие
    2) привычное - легким = поиск ответа на вопрос, как писать Юнит тесты проще, качественнее; где-то тут пробовать ТДД.
    3) легкое - приятным = смотреть в оба, наблюдать за своим ТДД; понять, что ошибаюсь чаще чем кажется (отсюда то самое "не верю!"), понять, что наконец-то могу делать управляемый рефакторинг; привыкнуть, что все под контролем...

    ОтветитьУдалить