Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

"К коду тестов нужно относиться так же, как и к коду продукта".

Недели не проходит, чтобы кто-нибудь об этом не заявил в докладе, статье, посте на LinkedIn.

Я согласен. Вы должны обращаться с кодом тестов так же, как и с кодом продукта. Проблема тут в том, что просто заявить "вы должны" недостаточно, чтобы это магическим образом произошло за одну ночь. К сожалению, я крайне редко вижу, чтобы сказавший это человек поделился практически применимыми советами, как же обращаться с кодом тестов аналогично коду продукта.

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

Контроль версий

Это, мне кажется, понятно и ежу. Если ваши тесты не подлежат контролю версий – их не существует. Если вы не храните тесты в Git или любой другой предпочитаемой вами системе контроля версий, вы никаким образом не сможете эффективно работать над ними совместно с коллегами, а следующий пункт в моем списке будет просто невыполним.

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

Запускайте ваши тесты на конвейере сборки

Ваши тесты бесполезны, пока не запущены – если не учитывать исследование системы, которым вы заняты, пока пишете их. И вы, возможно, хотите часто прогонять ваши тесты – в идеале при любом значимом изменении от разработчиков. Поэтому почему бы не автоматизировать процесс запуска тестов каждый раз, когда разработчик передает новый код в систему контроля версий? Или каждый раз, когда вы хотите создать готовый для деплоя на прод билд?

Если вы не автоматизируете процесс запуска тестов, вы с шансами забудете про них. Сделайте их частью вашего конвейера и используйте для проверки того, что созданный вашей командой код все еще ведет себя согласно закодированным в тестах ожиданиям. Каждый. Божий. Раз.

Используйте статический анализ кода и средства контроля качества кода

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

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

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

Для статического анализа и контроля качества кода подходит множество инструментов – некоторые из них умеют и это, и то. Лично я люблю StyleCop и пользуюсь им, дабы код RestAssured.Net был максимально чистым, ясным и согласованным.

Тестируйте код ваших тестов

Нас, как тестировщиков, волнует качество. Хоть мы и не хранители качества, но мы делаем все возможное, чтобы убедиться, что качество созданного командой продукта соответствует ожиданиям пользователей и других заинтересованных лиц. К сожалению, мы не всегда применяем этот подход к создаваемым нами тестам. В ходе моей карьеры я видел и писал множество тестов, которые явно проектировались на основании философии "оно компилируется и показывает зеленую галочку, чего еще тебе надо?"

Однако тесты тоже могут страдать от нехватки качества. Они могут выдавать ложноположительные результаты – это раздражает, но их хотя бы легко обнаружить. Что еще хуже, тесты могут выдавать ложноотрицательные результаты, и в результате нежелательные побочные эффекты и даже серьезные баги ускользают от нас незамеченными.

Поэтому тестируйте свои тесты, убедитесь, что они дают ценную и надежную информацию как в случае успешного срабатывания, так и в случае падения. Для этого даже есть специальные инструменты – так почему вы все еще не заняты тестированием тестов?

Применяйте принципы объектно-ориентированного программирования

За последние шестнадцать лет я прилично наловчился отличать автоматизацию, созданную умеющими программировать, от автоматизации, созданной теми, кто просто изучил API инструмента или библиотеки. Разница тут в структуре. Первые создают хорошо структурированный – и, как результат, читабельный и легкий в поддержке – код, а вторые зачастую не выходят за рамки тестов, сценарно перечисляющих сотни маленьких шажочков. Кликните тут. Напечатайте здесь. Отметьте этот чекбокс. Снимите отметку.

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

Пишите тесты в паре

Возможно, вы слышали о парном / групповом / совместном программировании. Знаете, что? Этим можно заниматься и при создании тестов. На самом деле этим нужно заниматься, создавая тесты. Нет лучше способа улучшить ваши тесты, чем дополнительная пара (или несколько пар) глаз. К тому же вы бесплатно научитесь чему-то. Сплошные плюсы и никаких минусов.

Считайте себя разработчиком, обращайтесь с собой как разработчиком, и ваш код улучшится

Последняя, возможно, наиболее важная моя рекомендация – все вышеперечисленные советы можно в какой-то степени свести к этому:

Если вы пишете код, проверяющий другие участки кода, то вы разработчик.

Вот, я это сказал.

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

Я уверен, что эти советы помогут вам предпринять полезные шаги в нужном направлении.

Идите и начните работать с кодом тестов так же, как с кодом продукта!

Читать статью полностью