Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Признак 1: Вы автоматизируете ВСЁ

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

Признак 2: Один тест проверяет все на свете

Как замечает великий Николай Адволодкин: «В UI-автоматизации каждый шаг — это шанс что-то сломать». Поэтому рекомендуется создавать атомарные тесты — проверяющие что-то одно и выполняющиеся очень быстро. Лучше иметь сто небольших тестов, каждый из которых выполняется меньше 30 секунд, чем десять тестов по пять минут. Малые тесты снижают риск ложноотрицательных результатов.

Признак 3: Чрезмерная абстракция тестового кода

Следовать принципу «Don’t Repeat Yourself» (не повторяйся) — отличная идея, но её можно довести до крайности. Например, если тест заканчивается так:

assertErrorMessage()

тогда поддерживающему тест придётся искать определение метода, чтобы понять, что тест проверяет. Лучше сделать явно:

cy.get('#error').invoke('text').should('contain', 'card is expired')

Так сразу видно, какое сообщение ожидается, и где его искать.

Признак 4: Постоянная переделка тестов под новые инструменты автоматизации

Периодическое обновление тестов — это хорошо, но если тесты работают и проходят, нет смысла переходить на новый инструмент. Это создаёт дополнительную работу для вас и команды. Есть американская поговорка: «Если работает, не трогай». Если ваши тесты стали нестабильными или сложными для поддержки, тогда стоит искать новый инструмент, в противном случае — цените то, что у вас уже есть.

Главная цель автоматизации тестов — давать надёжный и эффективный способ проверки кода продукта. Код тестов должен быть читаемым и удобным для поддержки. Всё, что не соответствует этим целям, скорее всего будет оверинжинирингом!

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