Оверинжиниринг автотестов — чрезмерное усложнение автоматизированных тестов и фреймворков, выходящее за рамки потребностей проекта и целей, стоящих перед QA-командой. Это проявляется в создании избыточного количества функций, уровней абстракции и сложных архитектурных решений, которые делают тесты громоздкими.
1: Вы автоматизируете ВСЁ
Не всё стоит автоматизировать. Некоторые тесты объективно сложно автоматизировать, и именно такие тесты чаще всего оказываются нестабильными и требуют постоянного обслуживания. В любом случае рекомендуется проводить ручное исследовательское тестирование, так почему бы не оставить сложные тесты в ручном виде, экономя время и нервы?
2: Проверка слишком большого количества элементов в одном тесте
Как справедливо замечают, в UI-автоматизации каждый шаг в тесте — это дополнительная вероятность, что что-то пойдёт не так». Поэтому он рекомендует делать атомарные тесты — проверяющие только что-то одно, и выполняющиеся очень быстро. Лучше иметь сто маленьких тестов, каждый из которых занимает менее тридцати секунд, чем десять тестов по пять минут. Маленькие тесты реже дают ложно-позитивные результаты.
3: Чрезмерное абстрагирование кода тестов
Правило «Не повторяйся» из Азбуки чистого кода — отличная идея, но ее не нужно доводить до крайности. Если ваш тест заканчивается вызовом вроде:assertErrorMessage(),
то человеку, который будет потом обслуживать этот тест, придётся искать определение этого метода, чтобы понять, что именно проверяется.
Гораздо удобнее и понятнее писать так:cy.get('#error').invoke('text').should('contain', 'card is expired')Это сразу показывает, какое сообщение об ошибке ожидается и где его искать.
4: Постоянное переписывание тестов под новые инструменты автоматизации
Обновлять тесты время от времени — хорошая практика, но если ваши тесты и так нормально работают и проходят, нет смысла менять инструмент только ради инструмента. Это только создаёт дополнительную нагрузку для вас и QA-команды. Есть американская пословица: «Не сломалось — не чини». Если что-то нормально работает, не нужно это менять. Если же тесты стали нестабильными или их сложно поддерживать, тогда стоит подумать о новом инструменте. В противном случае — довольствуйтесь тем, что есть.»
5. У вас постоянно происходит рефакторинг вашего фреймворка. Разумеется, фреймворк вы писали, потому что ни одно из решений на селениде не подходило под ваш уникальный проект.
Если серьезно, есть такая проблема, что автоматизаторы не любят писать автотесты) Любят писать фреймворк. Код пишется, тестов не прибавляется