О TDD И "гигиене мозга" (C)

Что мы знаем о TDD?

http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Добавление теста

Запуск всех тестов: убедиться, что новые тесты не проходят

Написать код

Запуск всех тестов: убедиться, что все тесты проходят

Рефакторинг

Повторить цикл

Нам важны все эти этапы? Стоит ли рассматривать TDD как "серебряную пулю"? Усложняет ли или упрощает TDD разработку?

Первое, что я хочу написать - "серебряной пули - НЕТ". НЕТ и не будет.

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

Так и с TDD, RUP, "водопадом", шаблонами от GoF.. Прочими "крутыми практиками"..

ВСЕ они конечно хороши. Но! Мозги включать надо - ВСЕГДА. Если если "нет воды", то глупо - "мыть руки".

Test First! Ага! Здорово!

ВСЕГДА Test First!

А если мы не знаем - что мы вообще делаем и что из этого получится - тоже Test First?

Мой ответ - "КОНЕЧНО нет".

Давайте попробуем ввяжемся в драку, а там посмотрим - что получится. Может и тесты. А может и ещё, что поинтереснее.

Когда ТОЧНО нужны тесты?

Моё мнение - если "сторонняя" Группа Качества (или не дай Бог - ПОЛЬЗОВАТЕЛИ) находит ОЧЕРЕДНУЮ ошибку, которой нет в Базе Ошибок, то тут уж точно - ТЕСТ НЕОБХОДИМ.

Но это - не Test First, это Test After. Сделали. Выпустили. Нашли ошибку - будьте любезны - ПЕРЕД исправлением ОШИБКИ - написать тест, если он конечно не КОСМИЧЕСКИ СЛОЖЕН (я мало таких видел).

Написали тест - исправляйте ошибку с лёгким сердцем. В следующий раз - вы её (а она - появится и не раз, не будьте оптимистами) - СРАЗУ найдёте.

Исправили ПЯТЬ ошибок - у вас УЖЕ есть БАЗА из пяти тестов. Просто, не правда ли?

Когда Test First?

А вот когда:

Вы ЗНАЕТЕ, что вам делать, но не договорились со "смежниками" откуда какие данные будут поступать и куда уходить.

А начальство включило вам задачу в план. И делать надо СЕГОДНЯ.

Вот тут - Test First.

Делаем тест. Придумываем вход и отправляем выход "куда-то". Желательно в эталонные файлы теста, которые потом будут сравниваться.

И спокойно пишем свой код. И отлаживаем его. Наблюдая за тестированием преобразования "вход-выход". Не более того.

Но! Вы можете придумать несколько входов и получить несколько выходов - на то вы и хороший разработчик. И в итоге получаете ОТЛАЖЕННЫЙ код. На детерминированном входе и детерминированном выходе.

И не зависите от смежников.

И получаете "бесплатно" ещё и "комплект тестов", который конечно не стоит выкидывать. А стоит включить в базу тестов. Они потом вам ещё пригодятся. Особенно когда смежники - раскочегарятся.

Если вы "действительно хороший разработчик" - добавляете ещё несколько тестов на граничные условия. Test First.

И ВСЁ - СВОЮ работу - вы СДЕЛАЛИ. Дальше - дело за смежниками.

Сам регулярно так делаю. И счастлив.

Когда ТОЧНО надо писать тест?

Моё мнение - тест ТОЧНО надо писать, когда мы попадаем в "программистские качели". Пока читаем тут:
http://18delphi.blogspot.com/2013/03/blog-post.html

... to be continued ...