Об использовании TDD Что такое TDD? Test-driven development или разработка через тестирование — это техника программирования, в соответствии с которой написание кода происходит по следующему алгоритму: 1 Написание тестов. Да, написание тестов происходит перед написанием любого, даже самого простого, кода. Например, если вы хотите объявить новую функцию, напишите тест, который просто ее вызывает и проверяет результат. 2 Проверка того, что тесты не проходят. В примере с функцией тест даже не будет компилироваться, потому что функция еще не объявлена. 3 Написание кода. Это должен быть наиболее простой код, обеспечивающий срабатывание теста, в нашем примере — объявление функции, возвращающей константу. 4 Подтверждение того, что тесты проходят. Теперь, когда код написан, все тесты, включая последний написанный, должны компилироваться и проходить. Если это не так, следует вернуться к шагу 3. 5 Произведение рефакторинга и возврат к шагу 1. Бояться нечего, потому что весь код покрыт тестами. Откладывать рефакторинг на потом не стоит. Потом вы будете хуже помнить код и вообще вам будет некогда. Чем меньше времени нужно на выполнение одной такой миниитерации, тем лучше. В идеале это время не должно превышать пары минут. Некоторые популярные заблуждения в отношении TDD: 1 «Написание тестов отнимает время». В действительности написание тестов экономит время. Допустим, вы пишите сайт. Как убедиться, что новое изменение работает и не привело к появлениям новых неполадок? Не перестало ли что-то работать в результате рефакторинга? Если автоматических тестов нет, нужно вручную все проверить, на что уйдет много времени. А если у вас есть тесты, достаточно запустить их и увидеть результат через несколько секунд. 2 «Это работает, только если писать проект с нуля». Ничто не мешает писать новый код для данного проекта по TDD. Если у вас есть старый, проверенный временем код, который просто работает, зачем покрывать его тестами? Если же с кодом постоянно возникают проблемы, вам все равно придется его переписать, а новый код в соответствии с TDD будет покрыт тестами. 3 «Лучше мы напишем код, а потом тесты». Это не работает. Во-первых, потом у вас не будет времени. Во-вторых, даже если потом вы напишите какие-то тесты, они будут намного хуже покрывать код, чем тесты, написанные во время разработки через тестирование. В-третьих, если при написании кода не беспокоиться о том, как вы будите его тестировать, потом вы просто не сможете написать для него тесты. Работая по TDD, вы: 1 Получаете наиболее полные тесты. Степень покрытия тестами кода, написанного по TDD (96.5% строк кода было выполнено хотя бы один раз), существенно превышает степень покрытия кода, тесты для которого писались в конце разработки (70.4% строк кода). 2 Сразу выявляете большую часть ошибок. Откладывая поиск и исправление ошибок на потом, вы существенно рискуете сорвать сроки. 3 Не боитесь делать рефакторинг. В любой момент времени весь код покрыт тестами. Если в результате рефакторинга что-то отвалится, вы сразу узнаете об этом и устраните проблему. Вы ничем не рискуете. 4 Получаете более продуманный код. В «обычных» проектах код часто напоминает спагетти и непонятно, как написать для него тесты. В случае написания кода с TDD код намного более структурирован, классы делают простые вещи и имеют понятный интерфейс, их легко использовать повторно. 5 Имеете документацию в виде тестов. Обычно программисты не очень любят писать документацию, зато с написанием кода проблем не возникает. Модульные тесты представляют собой замечательно описание интерфейсов классов и примеры их использования.
