Home

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

В этой статье я хочу глубже разобраться в вопросе, заданном мне Сайфуддином Раджем, подписчиком моей (уже прекратившей существование) рассылки. Он попросил меня более подробно остановиться на концепции «значимой автоматизации», и дать рекомендации, как сделать ее таковой. Надеюсь, я смогу ответить на этот вопрос.

Чтобы грамотно обсудить, что значит «значимая», нам нужно рабочее определение. Не претендую на то, что мое определение «значимой автоматизации» исчерпывающе, но базировать свои мысли буду на нем. С этого и начнем:

Значимая автоматизация – это автоматизация, написанная для получения ценной информации о качестве нашего продукта (когда мы пишем проверки), или помогающая выявить эту информацию эффективнее (когда мы используем автоматизацию в иной форме).

Повторюсь, это, вероятно, не идеальное определение (но много ли вы видели идеальных?), но для начала сойдет. Разберемся с ним и детальнее взглянем на значимость автоматизации.

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

Тесты дают мне важную для кого-то информацию о качестве продукта.

Тут я следую определению качестве Джерри Вайнберга – «ценность для кого-либо». Тесты, созданные мной, должны проверять нечто важное и значимое для какого-то человека. Это может быть, например, конечный пользователь (этот виджет еще работает?) или команда разработки (как у нас дела с качеством кода?).

Тест должен давать ценную информацию, если прошел успешно – «о, свойства нашего виджета, которые мы проверяем, не поменялись с последнего коммита», а также при падении – «о, кто-то внедрил код, который не соответствует нашим договоренностям о стандартах качества».

Тесты дают информацию значимым образом.

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

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

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

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

«Действительно ли нам нужна информация от этого теста?»

Повторюсь, создание тестов значимо только тогда, когда предоставляемая ими при прохождении или падении информация кому-то нужна. Тесты занимают время, место и ресурсы, и всего этого всегда не хватает. Мудро выбирайте, какие тесты писать, и не забывайте учитывать усилия по поддержке этих тестов. Знаю, предсказывать будущее трудно, но приложите все усилия.

Кстати, если вы или ваша команда легко и быстро ответили «да» на этот вопрос, переверните его и спросите себя:

«Что может случиться, если мы не получим информацию от этого теста?»

Это поможет вам еще критичнее задуматься, создавать ли тест и тратить ли на него ресурсы. Вновь учтите разработку, запуск и поддержку. А если вы сомневаетесь, добавлять ли существующий тест в процесс развертывания, то вот еще одна вариация этого вопроса:

«Действительно ли информация от этого теста необходима нам перед деплоем?»

и

«Что может случиться, если мы не получим эту информацию до деплоя?»

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

Также не попадайтесь на крючок создания автоматизации просто потому, что менеджер или некто, уверенный, что стоит выше вас, говорит вам это делать. Безусловно, у них могут быть резоны, но попросите их объяснить, почему добавление теста или даже целой категории тестов будет значимо для проекта. Их ответ на этот вопрос расскажет вам все о том, понимают ли они, о чем говорят. Не бойтесь оспаривать их решения.

И, наконец, не пишите тесты только для того, чтобы добиться каких-то оговоренных уровней покрытия, или потому, что ваши критерии готовности утверждают, что тест должен быть написан. Это, как правило, количественные метрики, не имеющие никакого отношения к качественным аспектам тестов, которые должны интересовать вас куда больше. Фраза «качество лучше количества» появилась не на пустом месте.

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

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