"Всё уже придумано до нас"

http://delphi.frantic.im/delphi-tdd/

Надеюсь, что автор не обидится, если я его процитирую:

"Беда вводных статей по тестированию кода в том, что они описывают правила написания тестов как догму: “делайте так, только так и никак иначе, потому что так надо”. Догма не гибкая и убивает креативность, а написание тестов требует гибкости и креативности. В этом случае лучше принять правило кармы: “делайте добрые дела и с вами будут случаться хорошие вещи, делайте их так, как умеете и так, как вам это нравится”. Эту формулировки мысли я почерпнул из замечательной книги –The Way of Testivus (очень рекомендую к прочтению). Перевод основных ее мыслей – в конце статьи.

Нужно понимать, что идеально правильного теста не существует. Вспомните свой код, который казался Вам вершиной инженерной мысли год или два назад. Наверняка сейчас, набравшись больше опыта, Вы его таким уже не считаете. С тестами та же история – идеальный тест сегодня уже не будет таким для Вас завтра. Поэтому, не пытайтесь сделать все безупречно! Начинайте с простого! Экспериментируйте! Развивайте свой код и свои тесты итерациями, каждый раз улучшая их структуру и содержание. А если Вы сталкиваетесь с трудностями – почитайте советы опытных разработчиков, наверняка они через это уже прошли.

Также забудьте о 100% покрытии кода тестами (о котором так любят говорить задроты). Оно просто того не стоит. Здесь отлично работает правило 80/20. Всего 20% усилий сможет дать Вам проверку 80% Вашего кода (а это намного больше чем вообще ничего). К остальным 80% усилий, на мой взгляд, относится тестирование графического интерфейса. Если Вы построили приложение так, что UI используется только для передачи данных во внутрь приложения и для вывода результатов, достаточно протестировать только этот внутренний движок.

И немого информации для тех, кто считает тестирование слишком затратным (наверняка, такое ошибочное мнение складывается только из-за небольших трудностей, которые тяжело преодолеть думая о тестах как о догме). Написание теста действительно занимает больше времени, чем ручная проверка и исправление проблем через отладчик, прямо на месте. Но если посмотреть в перспективе – это очень выгодное вложение. Автоматический тест выполняется за доли секунд, ему никогда не лень и он всегда внимателен (в отличии от человека). Если одну и ту же часть программы Вы проверяете 5-7 раз вручную, уже на этом этапе тест бы себя окупил. А если подумать о регрессии (ошибка в одном месте ломает что-то в другом) тесты – незаменимая вещь."

Я лично - готов подписаться под КАЖДОЙ буквой из приведённой цитаты. Лучше - и не скажешь.

Опять же ЗНАКОМО на все 100%:

"Но есть проблемы, не весьма инженерные. Если Вы работаете в команде над проектом заказчика, последний с 99% вероятностью будет против введения юнит-тестирования, т.к. это не дает очевидных видимых для него улучшений. Можно попробовать объяснить, но практика показывает что лучше начинать изменения изнутри, маленькими шагами. Попробуйте внедрить тесты в проект, после нескольких месяцев вы сможете понять насколько проще стал процесс разработки.

Бывает и так, что в команде разработчиков к идее автоматического тестирования относятся весьма пессимистично. В таком случае Вы можете попробовать этот подход сами в отдельной ветке (Вы же используете систему контроля версий?) и потом, если эксперимент удастся, показать результаты своей команде. Очень вероятно, что на живом примере ваши коллеги изменят свою точку зрения.

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

Понимаю, что перебираю с цитированием, но вот то - до чего я дошёл (и не раз озвучивал устно), но так и не смог написать и то, что "за меня" написал автор статьи:

"Советы из личного опыта:

1. Делайте тесты «плоскими», без if, while и т.д. В тесте не должно быть логики.
2. Запускайте тесты как можно чаще. Слишком медленные можно отключить в DUnit (если то, над чем Вы работаете, на них не влияет).
3. Начинайте с простого. Да, в интернете есть много хитрых инструментов для тестирования, не повышайте сложность без необходимости.
4. Если используете Continuous Integration, включите запуск консольного варианта тестового проекта в скрипт сборки.
5. Тестирование не сделает Ваш проект успешным и не избавит от 100% багов. Но очень в этом поможет.

Советы от Testivus (вольный перевод)

1. Если пишете код, пишите тесты
2. Не воспринимайте тестирование как догму
3. Воспринимайте тестирование как карму
4. Думайте о коде и тесте как об одном целом
5. Тестирование важней чем ограничивающие правила
6. Лучше всего писать тесты когда код еще горячий
7. Тесты, которые не запускаются систематично, пустая трата времени
8. Неидеальный тест сегодня лучше, чем идеальный тест когда-то в будущем
9. Некрасивый тест лучше чем вообще без теста
10. Хорошие тесты проваливаются"

И КРАЙНЕ советую - прочитать ВСЕ комментарии внизу статьи.

Там ещё маленький холиварчик про FreeAndNil. Я лично предпочитаю использовать его - ВЕЗДЕ.

Update. Один мой коллега, который ПЛОТНО занимается Unit-тестированием, после прочтения данной статьи написал лишь - "Да, сильно.". Это многое значит.