Home

Оригинал статьи: http://www.ontestautomation.com/monitoring-the-quality-of-your-test-automation-code/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

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

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

Аргумент "за": создание автотестов – это разработка ПО.

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

Аргумент "за": код автотестов бережет код продукта

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

Аргумент "против": выпуск новых фич на данный момент приоритетнее

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

Аргумент "против": код автотестов – это мертворожденный код.

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

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

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

Обсудить в форуме.