Тестирование: начало (ч.2)

Размышления на тему: "что надо сделать, чтобы превратить загадочное слово 'тестирование' в нечто реально полезное для разработчиков?"
Ответить на ряд вопросов:
1. Чего мы хотим добиться?
2. Нужно ли нам это?
3. Можем ли мы это себе позволить?
4. Заниматься этим систематически, т.е. постоянно (это не вопрос, а утверждение).

1. Чего мы хотим добиться?

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

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

И получается, что из множества ответов на вопрос "Чего мы хотим добиться?" разумно оставить два:

• более быстрой и "уверенной" разработки (см. TDD)
• раннее обнаружение ошибок в новом и/или в измененном коде. В идеале, это промежуточный шаг между написание кода и коммитом в SVN с отчетом "все сделано".
  Опять же, это касается только разработчиков

2. Нужно ли нам это?

Скорее всего нужно. Но есть есть 2 небольших момента:

• это довольно серьезная активность на проекте, которая требует определенных ресурсов, в т.ч. времени и знаний
• это может стать серьезным ударом по самооценке для "крутых программеров", которые "все знаю"

Вообщем, переходим к п.3.

3. Можем ли мы это себе позволить?

Как не парадоксально, но на некоторых из предыдущих проектов ответ был отрицательным. Для себя я выделил несколько групп условий:

• наличие человеческих ресурсов (в т. ч. знания и желание)
• реализуемость тестирования
• наличие аппаратных ресурсов
• поддержка и понимание со стороны товарищей, которые "рулят" проектом и принимают решения

По поводу человеческих ресурсов: в проекте должен быть хотя бы один человек, который хоть немного (а лучше "много") представляет как и зачем это делается и готов поделится своими знаниями. Очень желательно, чтобы эта персона имела "право голоса" - официальный или не официальный лидер, или человек, который умеет находить подходы к этим самым лидерам.
Также часто встречаются явления "не умею" + "не хочу". Тут помогают: а) всякого рода тренинги (от бесед в курилке, до специально организованных мероприятий) б) рычаги воздействия типа "так будет лучше" и "это надо делать".
О братьях наших меньших: в случае с индусскими командами уже этот пункт может стать труднопреодолимым препятствием.

По поводу реализуемости тестирования: есть ряд случаев в которых тестирование не возможно очень затруднительно. У нас были сложности с бизнес логикой в хранимых процедурах, с GUI в небольших приложениях, с унаследованными кусками кода в виде "единой и неделимой" глыбы.

По поводу наличия аппаратных ресурсов. Тут довольно просто:

• желательно, чтобы разработчика не напрягало запускать тесты очень часто (ну скажем, перед каждым коммитом в SVN)
• желательно наличие CI сборок - через пару минут после комита, автоматически начинается сборка приложения и прогон модульных тестов

И наконец "поддержка и понимание со стороны товарищей, которые "рулят" проектом и принимают решения". Как правило, понимание что "это процесс нужный", что "это best practice" и что "на это нужно дополнительное время" есть. Но часто упускают из вида 2 пункта:

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

4. Заниматься этим систематически, т.е. постоянно

Ну тут тоже, все довольно просто:

• Написание тестов по сложности сравнимо с написанием бизнес логики. И этому надо учится, пробовать и т.д. (оказывается, знания только JUnit не достаточно ;) )
• Если на проекте пишутся модульные тесты, то этим должны заниматься все(или, по крайней мере, должны все пользоваться). Очень желательно иметь возможность регулярно прогонять все тесты (см. CI сборки).
• Тесты это код, который надо дописывать/доделывать, запускать и проверять работоспособность и т.д. Ситуация "не компилируются или не проходят тесты" равносильна ситуации "не собирается или не работает основной код". Желание закоментировать неработающий тест должно восприниматься как, например, удалить неработающую страницу логина.