Впервые «автоматизированное тестирование» появилось в моей жизни в конце 2006 года, когда я ещё работал тестировщиком в одной широко известной компании. Как сейчас помню: мутили мы их на гремучей смеси bash’а, perl’а и PL/SQL’я. Тесты по своей сути были интеграционными, т.е. должны были запускать не только тестируемую программу, но и весь тестовый стенд (а это несколько серверов). Однако потом я хапнул экспы, качнул очередной левел и плавно переместился в стан программистов. Поэтому автотестирование стало интересовать меня только в разрезе Unit-тестирования...
Впервые «автоматизированное тестирование» появилось в моей жизни в конце 2006 года, когда я ещё работал тестировщиком в одной широко известной компании. Как сейчас помню: мутили мы их на гремучей смеси bash’а, perl’а и PL/SQL’я. Тесты по своей сути были интеграционными, т.е. должны были запускать не только тестируемую программу, но и весь тестовый стенд (а это несколько серверов). Однако потом я хапнул экспы, качнул очередной левел и плавно переместился в стан программистов. Поэтому автотестирование стало интересовать меня только в разрезе Unit-тестирования (которое требовало гораздо меньше усилий чем интеграционное, но об этом позже), практически не представленного в Российских компаниях. Причины этого озвучивались весьма банальные – руководство не желало тратить на это время (а следовательно и деньги), программистам же было либо лениво, либо нафиг не нужно. И если со вторым тезисом можно бороться настойчивым внушением (самовнушением, хе-хе )) ), то с первой причиной не очень-то и поборешься.
Проблема в том, что в любой иностранной литературе, в которой хоть как-то освещается вопрос unit-тестирования (кстати, отечественных изданий по этой теме практически нет) наивно написано, что нужно выделять ресурсы, нужно планировать эту деятельность, нужно ещё много чего хорошего. Но авторы этих книжек не знают, что есть страна Россия )), в которой многие разработчики софта любого индуса в ужас приведут своими кодерскими навыками. Мир просто не в курсе, что Россия – родина экстремального программирования. На западе «eXtreme Programming» это красивый рекламный слоган, а у нас это отражение самой сути процесса производства ПО. Именно поэтому нам жизненно важно использовать юнит-тестирование, иначе так и будем клепать проекты, которые уже после миллиона строчек кода "рушатся" под своей тяжестью.
Лично для себя я установил такие правила:
- тестируем класс руками
- составляем список всех методов класса
- из полученного списка выкидываем get и set методы (т.к. вероятность проскакивания ошибки в таких методах минимальна, хотя если кто-то не уверен в своих силах, то пишите тесты и для них)
- из оставшегося списка выкидываем все закрытые методы
- из оставшегося списка выкидываем все методы, которые так или иначе вызываются другими методами из этот списка. Т.е. если в списке есть 2 функции f() и g(), причем g() вызывается из f(), то g() выкидываем из списка (в некоторых случаях, если функция g имеет какую-то сложную логику, то её можно оставить в списке)
- пишем юниттесты на оставшиеся в списке функции
При таком подходе в списке будет оставаться не более 30-50% функций, что весьма уменьшает время требующееся на написание тестов.
Теперь коснемся трудозатрат. Лично у меня написание тестов для класса с 13-15 методами занимает в среднем 30-50 минут. Не так уж и плохо, да? Так же стоит учесть, что дольше всего пишется первый тест, остальные, как правило, копипастятся и доводятся до ума минимальным набором изменений (как правило, на это уходит минут десять, не больше). Кстати, если у Вас в классе несколько функций потребовали больших трудозатрат на написание теста, то это серьезный повод задуматься – возможно, тестируемый класс превращается в God object.
Менее часа в день это не очень большая плата за возможность смело дорабатывать и рефакторить исходники. Однако даже если пятьдесят минут в день это непозволительная роскошь для Вас, то возможно стоит подумать о написании нескольких интеграционных тестов на наиболее важные use-кейсы. Можно писать интеграционные автотесты из расчета 2-3 автотеста в неделю (имеется ввиду что один разработчик будет выдавать 2-3 теста в неделю). Если наработать минимальный фреймворк для тестирования, то создание этой малости тестов потребует минимум времени, а принесет огромную пользу проекту.
Оптимально покрывать тестами все что можно покрыть, иначе шанс выхватить звездюлей за пропущенный баг будет оставаться высокой, хотя и не такой высокий как если бы автотесты не использовались бы вообще.
Ссылки по теме:
Менеджер тестирования
Unit-тесты часть 2