Ошибка №1. Некорректное использование ожиданий.
Вероятно, самая распространенная ошибка. Ее, как замечено, делает практически каждый начинающий тестировщик, каждый раз когда хочет “зафиксить” тест. Теперь ты знаешь что это плохо, но не знаешь насколько. Сейчас уточним.
Тесты дольше выполняются
Это кажется очевидным: ты вставляешь искусственную, hardcoded-паузу, но ты это делаешь без размышления. Конечно же, тест будет дольше выполняться, и если таких вещей много, а их обычно много, это замедляет процесс, ты получишь фидбек позднее, и конечно это все “не очень по эджайлу”. В результате набор выполняется более чем полчаса, или час, или еще дольше, это делает весь ваш pipeline “очень неправильным эджайлом”.
И если думаешь, что вставишь 2 секунды тут, 2 секунды там, то скорее всего и остальные тестировщики думают так же…
Бездумное применение “sleep-методов” запрещено
На скриншоте ниже показан метод .open(), и сразу после него запрограммирована пауза на 2 секунды (как бы ожидание загрузки страницы).
Но тут нужно учесть, что происходит внутри метода .open(). Тестировщик, добавивший ожидание в 2 секунды, не заметил ожидания, которое уже предусмотрено методом.
В принципе, 4 секунды “пустого ожидания” разумеется не выглядят катастрофой, но в больших проектах, где может быть много sleep-методов (то есть много новичков-тестировщиков), все эти ожидания могут “преумножаться”, превращаясь в 10 секунд, или в 100 секунд, и создается реальная проблема в pipeline.
Тесты получаются “рваными”, нестабильными
Добавление ненужных ожиданий делает тест нестабильным, потому что не знаешь, сколько времени реально будет загружаться страница (или допустим один элемент). Посмотрим еще раз на предыдущий пример.
- Тестировщик Вася добавил 2 секунды при создании теста
- А тестировщик Коля добавил еще 2 секунды
Теперь представим, что запускаются эти тесты в таком “медленном” окружении, где эти тесты “упадут”; так что может возникнуть ситуация, когда кто-то может посмотреть эти тесты, но неправильно понять проблему, и добавить “на всякий случай” еще больше ожиданий, преумножая проблему.
Ок, проблему мы видим, а что делать вместо “пустых ожиданий”?
А решение здесь простое — вместо опасных “sleep”-ов везде применять “wait”-ы. Ну ОК, в 99% случаев.
А почему 99%? Потому что есть и такие сценарии, 1%, когда wait-методы плоховато работают. Это в принципе экстремальные кейсы, но с ними тоже сталкивался. В 99% случаев кажется, что сейчас подойдет любой метод, но когда возвращаешься к коду потом, оказывается что “wait”-ы все-таки лучшее решение.
Ошибка №2. Слишком сложные тесты.
Смотрим.
Второе распространенное заблуждение — стремиться писать “всеобъемлющие” тесты. То есть, слишком длинные и сложные для простых ситуаций. Обрати внимание, что внизу у нас проставлен таймаут 180 000 миллисекунд, то есть три минуты. Такой таймаут проставлен, потому что тест рассчитан примерно на такое время.
Так что, если любишь писать подобные тесты, нам нужно об этом поговорить.
Нет четкого понимания, что тест должен делать
Были ситуации, когда я писал большие сложные тесты, и через пару месяцев возвращался к ним, и не имел понятия, что этот тест делает. Конечно, можно представить, что другие тестировщики говорят, читая такой код.
Тест долго выполняется
Это очевидно: когда пишешь большой неупорядоченный тест, он будет долго выполняться, 3 минуты в примере выше.
Большие тесты провоцируют нестабильность
Что случается, когда пишешь большие тесты и запускаешь их? Да, большие тесты обычно нестабильные, просто потому что в них слишком много всего происходит, что значит: много шансов упасть.
Сложно дебажить
Да, такие тесты трудно обслуживать. Тест идет 3-5 минут, в нем куча оошибок, и пытаешься понять в какой строке ошибка, а потом пытаешься понять как ее исправить.
И как избежать этого?
Один тест должен быть посвящен лишь одной значимой вещи.
Не надо понимать слишком буквально: что такое, одна вещь, одна функция, “одна фича”, — это согласуют в команде. Это может быть одна функция, один компонент, или один end-to-end проход, и этот тест занимает, в идеале, не больше минуты.
Итак, у тебя один тест посвящен одной функции, и этот тест всегда понятен другим членам команды.
Ошибка №3. Зависимости в тестах.
В этом примере второй тест зависит от первого — в нем открывается URL тестируемой страницы. Это плохо, потому что:
Трудно выполнить один тест при сбое набора
Если второй тест упал по какой-то причине, то нельзя запустить этот тест, он же зависит от первого. Надо обязательно запустить оба теста. Что, конечно, заберет больше времени. Или надо рефакторить оба теста, о чем ниже.
Изменение порядка выполнения тестов приводит к их падению
Если еще кто-то придет и “просто-случайно” изменит порядок запуска этих тестов, они опять же начнут падать, потому что в TestBuddy они уже не в том порядке. Это тоже отдельный вопрос — нужно помнить правильный порядок запуска.
Сложно рефакторить код
Когда будешь рефакторить свои тесты, это будет сложно. Надо вспомнить все зависимости и как они работают в тесте, пофиксить их. Все это заберет много времени.
Что надо делать?
Надо еще раз вспомнить Пункт №3 — тесты должны быть независимы друг от друга.
Твоя цель: написать тесты, в идеале отдельные, как бы не полагающиеся друг на друга. И даже на какие-то данные со стороны. Это обеспечит гибкость, что бы не делалось — будь то рефакторинг, или просто реорганизация в наборе.
Еще раз.
- Лучше без Sleep.
- Не пишем длинные сложные тесты.
- Тесты не зависят друг от друга.
Если стараешься придерживаться этих нехитрых правил, то получаются стабильные и годные тесты.
P.S. Тут можно заметить, что далеко не всякий end-to-end набор будет выполняться меньше минуты. Такие сценарии как создание аккаунта, настройка большого приложения, и особенно обработка платежей могут занять больше. Главное все же тут не время, как то что не надо стремиться втиснуть все три перечисленных действия в один тест, ибо тогда они действительно займут 4-5 минут, если не больше. На модных JS-фреймворках, с правильной настройкой, и правильно подобранными данными, с E2E-проходом можно уложиться и в минуту.”
