Я постоянно натыкаюсь на посты в блогах или интересные презентации, которые дают мне пищу для размышлений. В последнее время изо всех сил пытался придумать стратегию, чтобы помочь разработчикам понять, когда им следует приступать к написанию тестов для своих программ.
Если вы верите в силу разработки через тестирование (Test-Driven Development, TDD), тогда ответ будет следующим. Вы начинаете писать тесты сразу после старта работы над проектом и так до конца, шаг за шагом. Я верю, что TDD может быть очень мощным средством разработки для создания модулей или компонентов.
Некоторые люди спрашивали меня, что я думаю по поводу комментариев создателя проекта Rails о целесообразности внедрения зависимостей. Как это часто бывает, я стал писать свои замечания в твиттере.
Потом по рекомендации Ian Barber я посмотрел презентацию Dan North под названием «Decisions, Decisions». Из нее следует, что стратегия по тестированию проекта уже разработана. Слайды презентации можно найти здесь.
Вы обязаны посмотреть ее полностью. В программировании большинство решений принимается без обдумывания. Поэтому, прежде чем принимать решение, надо рассмотреть преимущества и недостатки одного и другого подхода.
Давайте посмотрим на разработку через тестирование и без. В расчет принимается не качество кода или его защищенность. Речь идет об альтернативных издержках (упущенный доход). Делая выбор, я как раз не учел этот параметр.
Я допустил ошибку и вот почему.
В своей презентации Dan говорит про модель работы одной команды разработчиков, с которой сотрудничал некоторое время. Он был поражен большим объемом выполняемых работ. Ему пришлось потратить время для понимания общих принципов продуктивной модели работы. В повторении удачного процесса ведь нет ничего плохого.
Модель, которую он увидел, имеет прямое отношение к программированию. Он назвал ее «Spike and Stabilize». Смысл заключается в том, что вы пишете код, не тестируя его до тех пор, пока он не станет стабильной частью архитектуры приложения. После того, как часть кода написана, требуется проверить его надежность. Для этого пишется специальный тестировщик, который проверяет стабильность его работы. Если приложение работает без сбоев, то можно двигаться дальше.
Сейчас для меня крутость этого подхода очевидна. Получается, вы не только пишите код для приложения, но и получаете в свои руки контроль за каждым этапом производства программного продукта.
Альтернативные издержки огромны. Допустим, у вас есть прототип кода или даже какой-нибудь функционал, что еще можно было делать, пока тесты для этого кода пишутся?
Лагерь тех, кто «слишком занят, чтобы писать тесты» по-прежнему имеет много сторонников и мне кажется, что это явление принимает катастрофический размах. Хотелось бы присоединиться к Крестовому походу за тестирование.
Чтобы было совершенно ясно: я придаю большое значение созданию прототипов кода и только потом перехожу к процессу тестирования, чтобы получить стабильный прототип.
Я стараюсь делать прототип, прежде чем осуществлять какие-либо действия по написанию кода. Я привык так делать. Мой прототип, как правило, представляет собой сценарий командной строки, который пытается решить определенную задачу.
Ключевым моментом в модели «Spike and Stabilize» является определение стадии готовности кода. Если вы заметили ошибку, то работаете над исправлением ситуации до тех пор пока не получите стабильную версию.
Когда в следующий раз вы задумайтесь над процессом тестирования приложений, обратите внимание на модель «Spike and Stabilize». Конечно же, тестирование нужно проводить в обязательном порядке, но не все сразу.