Прошлым летом я подыскивал новую работу, к которой предъявлял некоторые требование. И доход был не самым определяющим из них. Искал интересные проекты, и хорошую среду для собственного профессионального роста. В таких случаях нужен критерий поиска, и я его придумал - автоматизированное тестирования, или готовность перейти к нему ближайшее время.
Увы, огромное число команд до сих пор не используют автотесты в своей работе, и даже не готовы рискнуть. Многие предложения были отвергнуты именно по этой причини. Печальный факт. Это первая причина, по которой я решил написать эту серию блогов – возможно кто-то рискнёт ( и обязательно выиграет! ). Ниже причины, по которым я пишу, и не собираюсь отказываться от тестов:
- Нам это надо. Нам – это программистам. Это наиболее важная причина. Мы всё равно тестируем: тыкаем кнопки в приложении, пишем консоль протестировать чужую библиотеку, или создаём тестовую форму проверки своего алгоритма.
- Сокращается время обратной связи. Работоспособность кода можно проверить в считанные секунды. Это намного быстрее, чем ручное тестирование. А свежий код легче править, пока каждая строчка живёт в голове.
- Улучшает архитектуру. Если сложно написать автоматизированный тест – значит грабли закрались в рабочий код. Это как сигнал тревоги – код в опасности.
- Защищает от будущих ошибок. Конечно, только в том случае тесты регулярно прогоняются на рабочем коде. Сложно даже вспомнить, сколько раз это спасало меня от ошибок в коде.
Чтобы быть честным до конца, стоит всё-таки признать: на начальном этапе вхождения в автоматизированное тестирование время разработки увеличивается в 3-4 раза. При интенсивном использование этот период длится 2-3 месяца, и потом время сокращается до 1.5-2 раз. Так стоит ли автоматизированное тестирование таких затрат? Стоит. Это вложение в надёжность и устойчивость программы. Тесты можно сравнить с фундаментом. Без него построить дом гораздо быстрее и дешевле. Но тогда не стоит удивляться последствиям.
Вторая причина – желание изложить свою точку зрения на то, как должны выглядеть тесты. Тесты – не менее важная часть проекта, чем рабочий код. Они нуждаются в поддержке и развитии, поэтому критически важно поддерживать их в хорошем виде. Написать плохие бесполезные тесты легче, нежели код системы. К счастью, ошибки при работе с тестами одинаковы, и уже хорошо систематизированы и описаны. Не так сложно их избежать, зная врага в лицо.
В последнее время я настолько привык писать тесты, что работа без них меня пугает. Да, именно так. Я боюсь писать непроверенный код. Как убедиться в работоспособности? Как рефакторить без вреда? Как быстро я могу проверить? Эти вопросы постоянно крутятся в голове при виде не покрытого тестами кода.
На этом хватит введения. Более подробно можно прочитать во многих книжках, но я бы рекомендовал две: Test Driven Development: By Example и The Art Of Unit Testing. Причём именно в такой последовательности. Кент Бек даёт хорошую идеологию модульного тестирования, а Рой Ошеров практическую базу для тестирования .net, и систематизирует основные ошибки при написании тестов.
У программиста, как у любого хорошего мастера должен быть набор инструментов, которыми он отлично владеет. В том числе и для автоматизированного тестирования. Поэтому в следующем сообщении рассмотрим “классический” инструмент – NUnit.
Комментариев нет:
Отправить комментарий