Работаю на большом проекте (длится несколько лет, всего занято 30-40 разработчиков, относительно высокая текучка). Проект — веб-приложение, по большому счету формоклепательство. Основные технологии: J2EE, Oracle, jQuery.
Одна из вещей, которая меня расстраивает на проекте: разработчики мало (относительно мало, относительно 100% покрытия) пишут тесты. Кто-то пишет от случая к случаю, кто-то не пишет вообще (еще и чужие выключают частенько, но речь не об этом).
Когда задаю вопрос, почему не написал тесты на новый код, часто слышу ответ: времени не было, собирался написать после выполнения задачи (т.е. когда код уже отлажен, закомичен и часто даже проверен тестировщиками). Для меня это очень странно, потому что у нас на проекте очень хорошая инфраструктура для тестов, их разработка тривиальна, не занимает много времени, ничего самому изобретать не надо, как правило. Я сам всегда пишу тесты для нового кода, мне так легче его проверить, чем собирать все приложение целиком, совершать телодвижения для проверки всего в интеграции. Но при этом я не пишу много тестов, не стремлюсь к полному покрытию, обычно это несколько смок-тестов и доп. проверки на хитрые случаи в зависимости от нетривиальности кода, своего рода баланс между временем на написание тестов и полнотой покрытия. Если требуется исправить ошибку, обычно сначала пишу тест, который локализует ошибку, затем исправляю код, и проверяю что тест проходит. В целом я считаю, что экономлю много времени уже на этом этапе, даже если забыть о пользе существования таких тестов на будущее (например, снижение риска переоткрытия ранее исправленных ошибок, что, к сожалению, на нашем проекте не редкость).
Теперь о чем мой вопрос. А есть ли вообще смысл писать тесты после отладки кода? Очевидный ответ да, ведь так будет больше шансов что функционал останется работоспособным в будущем, в него легче вносить изменения для меня несколько спорен. Во-первых, этот эффект проявится не сразу, а в каком-то туманном будущем. Во-вторых, вероятность что пользу почувствует именно автор, тоже далеко не 100%. С одной стороны это в перспективе демотивирует писать тесты, а с другой — снижает стимул писать именно хорошие, полезные тесты (да и сложнее отличить хорошие от плохих в этом случае) с большим покрытием. Ведь при отладке кода уже было исправлено много ошибок, если бы на каждую ошибку был написан тест, к завершению отладки мы бы получили пачку тестов, выявляющих проблемы, которые реально могут возникнуть.
Есть и другой момент в таком подходе. Когда пишешь тесты после выполнения задачи, к ним отношения как к некой дополнительной работе, которую можно делать, можно не делать, все равно никто проверять (тестировщики) не станут и по шее не дадут, как за ошибки. Забивание на тесты в данном случае это вполне объяснимое следствие. Но даже если тесты и будут написаны, это будет сделано через силу и вряд ли результат получится хорошего качества.
Третье возражение, это не смотря на всю простоту, поддержка и разработка тестов требуют каких-то затрат. Может оказаться что эти затраты никогда не отобьются. Заморозили фичу, удалили или полностью переделали заново, тоже не редкое явление. В случае разработки тестов до отладки кода, часть этих затрат (уверен, что в некоторых случаях эта часть превышает 100%) уже отбилась на этапе отладки. Поэтому возникает вопрос нужны ли вообще тесты, если речь идет не о разработке ядерного реактора и ценой ошибки можно пренебречь, если важнее эффективность в плане трудозатрат разработки.
Вторая тема, которую хотелось бы обсудить, это причины по которым разработчики не используют тесты для отладки кода. У меня есть некоторые размышления на этот счет, но хотелось бы послушать именно тех, кто не всегда пишет тесты и почему вы этого не делаете, что мешает начать писать.
Если есть успешный опыт внедрения процесса написания тестов в проекте, тоже было бы интересно послушать.
