- Большие тесты = проблемные
- Сложные и нечитабельные
- Абстракция
- Изоляция
- Приоритеты
- Правило ААА
- Селекторы
- Фиксированные ожидания
- Бессмыссленные имена
Если ты давно в ИТ, то знаешь, что хороших программных продуктов не бывает без тестирования, в частности автоматизированного.
Без тестирования, софт не будет работать как положено. Найти клиентов для такого софта очень сложно.
С ручным тестированием не все просто: полагаясь только на ручное тестирование, компания потратит много денег и времени. Это достаточно сложный и дорогой процесс.
Автоматизация помогает писать качественный софт: снижает затраты денег и делает цикл разработки короче.
Автоматизация помогает выдавать больше хорошего кода. Она экономит достаточно дорогое рабочее время тестировщиков; они могут заняться ручным тестированием и действиями, которые нельзя автоматизировать. Корректно написанные автоматизированные юнит-тесты служат страховкой для разработчиков, которым нужно рефакторить код и передавать в продакшен.
Известно, что, начинающие разработчики и тестировщики попадают в одни и те же ловушки при написании юнит-тестов, интеграционных тестов и сквозных (E2E) тестов.
Ниже мы собрали советы, которые помогут не попадать в такие ловушки.
Совет №1. Избегай «больших тестов»
В процессе разработки софт усложняется. Понятно, что чем сложнее сам софт, тем сложнее и тесты.
При стандартном подходе, придется несколько недель писать тесты и несколько месяцев их выполнять, это конечно не понравится команде. Разработчики не будут вечно ждать результатов тестирования, и сами тестировщики не будут тратить время на написание или бесконечное повторение дублирующихся тестов.
Изначальная установка на автоматизацию тестирования самых простых (или самых рискованных) частей программы — сильно сократит затраты времени. Тестировщики займутся ручным тестированием, или обнаруженными проблемными местами.
Долгое и сложное тестирование портит отношения между разработчиками и тестировщиками.
Совет №2. Убедись, что твои тесты простые и понятные
Программисты и тестировщики тратят больше времени на чтение чужого кода, а не на написание своего; поэтому делай свои тесты удобочитаемыми, насколько это возможно.
Твой код никогда не будет столь же прост и ясен как роман Хэмингуэя, но это не значит, что надо писать тесты так, чтобы никто, кроме тебя, не мог их понять.
Йони Голдберг назвал это Золотым Правилом Тестирования: тест должен быть написан так, чтобы каждый кто его читает, мгновенно понимал его предназначение.
Твой код будет нравиться тебе, а вся команда будет тебя любить, если твои тесты «читабельны».
Может случиться, что ты вернешься к своим тестам через год, и если они нормально написаны, ты не будешь задавать себе вопросы: «Что тут написано?» и «Для чего вообще этот тест?».
А если ты не понимаешь, для чего этот тест был предназначен, разумеется тест «нерабочий». А если ты не можешь с ним работать, то какую ценность он имеет для тебя и твоей команды?
Тест, назначение которого не помнишь ты сам, имеет нулевую ценность.
И да, нечитабельный код — это кошмар для разработчика, который должен его дебажить или рефакторить.
Советы о том, как писать простые и понятные юнит-тесты, можно найти в статье нашего читателя.
Совет №3. Давай без излишней абстракции
Добросовестный тестировщик знает, что нужно придерживаться принципа простоты. Не прибегай к абстракции слишком часто.
Помни: автоматизированные тесты — это НЕ код, который идет в продакшен.
Немного уточним.
Разумеется, нужно относиться к качеству тестового кода как к коду который идет в продакшен, он имеет ту же ценность; но существуют некие паттерны, и соглашения, которые важны для продакшен-кода, но не имеют большого значения для тестов.
Правило DRY («принцип неповторения», «Не повторяйся в коде», “Don’t Repeat Yourself”) заставляет тестировщиков избегать дубликации кода.
Но если этот принцип слишком буквально соблюдается в твоих тестах, они могут быть нечитабельными и непонятными. Итак, этот паттерн должен соблюдаться для продакшен-кода, но дважды подумай, прежде чем применять его в коде автоматизированных тестов. Лучше потрать время на написание подробной документации — с ее помощью сделав предназначение теста более ясным. Помни: читабельность тестов — выше Правила DRY.
Совет №4. Изолируй свои тесты, где это возможно
Когда что-то тестируешь много раз, а сами тесты не меняешь, то результаты будут ненадежными.
Если твой новый тест зависит от результатов предыдущего теста, будут проблемы. Если предыдущий тест неудачный или вообще повредил данные, всякий последующий тест будет, скорее всего, тоже неудачным, или выдаст некорректные результаты.
Изоляция тестов даст более надежные результаты, ведь лишь точные и надежные результаты сделают твои тесты по настоящему полезными.
Опытные тестировщики советуют: первый шаг перед тестированием — сбросить конфигурации и данные до дефолтных. Таким образом гарантируется, что каждый тест использует одинаковые данные, и значит защищен от любых внешних факторов.
Второй шаг: подтянуть данные, которые понадобятся для теста, с помощью API-запроса. Тесты могут запускаться независимо, и порядок выполнения неважен.
Совет №5. Определи приоритеты
В стандартном рабочем времени тестировщика всего 8 часов, и за это время надо успеть сделать много тестов, так что лучше делать их в порядке приоритета.
Присваивание приоритетов отдельным тестам — уменьшит вероятность того, что критически важный элемент приложения остается непроверенным.
Когда думаешь, какой приоритет присвоить тесту, прими во внимание две вещи:
● Какова вероятность, что пользователь получит ошибку именно в этом месте?
● В каких частях приложения ошибки абсолютно недопустимы?
Если в какой-либо части приложения ошибка маловероятна, а функционал не критически важный, значит, она должна быть внизу списка приоритетов на тестирование.
А вот в таких вещах, как регистрация пользователей или работа с пользовательскими данными — ошибки недопустимы.
В таких частях приложения всегда необходимо тщательное тестирование.
О том, как расставлять приоритеты в автоматизации, мы написали отдельную статью.
Совет № 6. Должна быть простая и последовательная структура тестов (правило ААА)
Простая и четкая структура тестов «в стиле ААА» делает их удобными для тебя самого.
Паттерн тестирования ААА («Arrange-Act-Assert», или проще «Настройка-Выполнение-Проверка») — это простая и эффективная структура тестов, которой легко следовать. Она обеспечивает хорошее качество кода, независимо от языка программирования.
Каждый тест должен проходить в три этапа:
1. «Настройка» (Arrange). Начни с описания, что нужно, чтобы начать писать тест. Далее посмотри на условия, и спроси себя, что нужно, чтобы тест «прошел». После этого, нужно разбить задачу на логические этапы и настрой тестовое окружение.
2. «Выполнение». Выполни свои тесты, следуя шагам, созданным на этапе 1.
3. «Проверка». После выполнения, проверь, что тесты ведут себя так, как от них ожидается.
Принятие в практику паттерна «ААА» избавит твое автоматизированное тестирование от ошибок.
Вот хорошая статья про AAA на английском.
Совет №7. Не пиши тесты на основе селекторов, которые могут непредсказуемо меняться
Написание тестов на основе элементов, которые легко могут быть изменены (особенно это относится к CSS-селекторам), это верный путь к негативному результату теста.
Ты будешь озадачен, почему тест «не прошел», ведь багов в нем нет.
Конечно, в нем нет багов, просто тест «просроченный».
Вместо того, чтобы опираться на селекторы, нужно сосредоточиться на вещах более стабильных, например на data-атрибутах. Разработчики вряд ли будут их менять, поэтому опирайся лучше на атрибуты.
Пожалуй еще один совет бонусом: не тестируй то, что не имеет отношения к требованиям (например, код, имеющий отношение к имплементации).
Такое тестирование может дать ложно-позитивные и ложно-негативные результаты.
Или же, тест упадет во время рефакторинга, то есть это ложно-негативный результат. Или тест НЕ упадет даже когда код работает неправильно, то есть ложно-позитивный результат.
Совет №8. Не прописывай фиксированное время ожидания
Фиксированное время ожидания в тестах — это ужасная идея, по многим причинам.
Тест может упасть, если в нем прописано меньшее время на реакцию, чем нужно приложению. Если время ожидания будет слишком большим, это делает тест затянутым, а значит неэффективным. Если ожидание будет слишком коротким, а приложение загружается долго, это приведет к ложно-негативному результату теста.
Вместо фиксированного времени, попробуй опираться на изменения в интерфейсе, точно как это делают пользователи программы. То есть ожидай, пока исчезнет значок загрузки, закончится анимация, или загрузится весь текст.Таким образом, твой тест должен опираться на поведение приложения, а не на фиксированное время ожидания.
Совет №9. Не создавай переменные с бессмысленными именами
Представь друга-разработчика, которому внезапно понадобился тест, написанный тобой полгода назад. Представь, каково ему читать тесты с именами переменных, которые не значат ничего, и которые невозможно понять.
Он может спросить: «А что здесь делает этот тест?» Что здесь означает это слово? Это название продукта? Имя клиента? Нечто важное, или полностью несущественное?
Использование бессмысленных названий делает тест нечитабельным и непонятным.
Используй имена переменных и названия файлов, связанные с продуктом, его функциями. И каждый кто будет читать тест, скажет тебе спасибо.
