Фантастические стеки автоматизации тестирования, и где они обитают. Есть ли среди них лучший?

Всем привет! С вами снова я, Иван Шевелёв, QA Lead в компании Denti.AI. Сегодня хотел обсудить наболевшую тему – лучший стек для автоматизации тестирования. 

Эта тема о-о-очень холиварная, каждый топит за свой стек, потому что работал на нём 10 лет ранее или просто потому, что он лучше всех, и быть по-другому не может! В коммерческом опыте я работал с 2.5 языками (JS/TS и Python – рука не поднимается разделить JS и TS) и большим количеством фреймворков (от уже deprecated до самых трендовых). В некоммерческом опыте сталкивался почти со всеми возможными стеками, кроме тех, что связаны с Ruby и C#.

У каждого фреймворка есть большое комьюнити, чатики, каналы, форумы и даже бизнес-завтраки! Если зайти на страничку любого фреймворка, то каждый из них – топ-1 в мире автоматизации тестирования. Но так ли это?

Давайте рассмотрим самые популярные связки на рынке сегодня. Оставлю в порядке убывания сложности погружения в стек, чтобы была какая-никакая сортировка.

Java + Selenide + JUnit

Сложный, но очень контролируемый стек за счёт возможностей языка. Очень выраженная типизация, контроль рантайма, широкое комьюнити и количество решений/инструментов. Также очень большая база знаний и решенных кейсов. Кажется, что сейчас стек медленно теряет свою актуальность, потому что:

• selenide работает на базе Selenium, хоть и весьма переработанный и улучшенный. Но каких-то киллер-фич ждать не стоит. Эдакий зрелый и полноценный гигант в мире авто-тестирования

• всё меньше команд используют чистую Java в своём стеке, сейчас в тренде python и go, следовательно, реже выбирают Java как общий стек для авто-тестов

• высокий порог входа. Если сравнить два курса – Python и Java, то будущий автоматизатор быстрее начнёт писать код на первом языке, чем на втором

TS + Playwright

На мой взгляд – это самый нейтральный и эффективный стек за счёт баланса между сложностью, контролируемостью и возможностями, но неидеальный за счёт работы TS (await будет сниться до конца дней, а работа с асинхронностью ещё дольше). Но главная фича кроется в фреймворке – Playwright.

Сейчас Playwright – самый трендовый фреймворк для авто-тестов, который развивается за счёт Microsoft. Постоянные обновления, киллер-фичи в работе с CDP (прямое взаимодействие с Network, моки браузерного API и прочее), новые паттерны автоматизации тестирования, интеграции с другими сервисами, разные виды дебаггинга (IDE, логи, собственный дебаггер с UI) и ещё много-много чего. На моей практике он работает гораздо быстрее selenium-based фреймворков, причём на порядок.

Итого:

• Playwright – значительный плюс

• TS – гибкая типизация, что тоже плюс

• работа через WS – быстро и надёжно

• но… беды и костыли с асинхронностью, тем более с импортом JS решений

• не работает с selenoid и подобным инструментами, только Moon (но зато в K8)

Python + Pytest + Selenium

Python – круто, модно, молодёжно! Множество курсов, как стать питонистом за 10 минут, не сказка ли? Python очень подкупает своей доступностью и простотой, а также гибким владением рантаймом (как выяснилось – не всегда, но чаще этого достаточно). Pytest – простой и надёжный раннер, который используется на всех уровнях пирамиды. Selenium… Ну, это selenium ?

Итого:

• просто вкатиться в язык

• большое коммьюнити, которое активно пополняется с каждым днём

• потихоньку повышается спрос на python, что тоже заметный плюс

• но… Selenium…

Python + Pytest + Playwright

Тоже нейтральный и эффективный стек, за счёт того, что есть свежая база знаний на python. Язык развивается, как и фреймворк (хотя и в ограниченном формате, т.к. основное направления для Playwright – JS/TS), мощный раннер.

Итого:

• включает плюсы использования Python

• включает плюсы использования Playwright

• отдельный раннер pytest для всех слоёв пирамиды

• но раннер – это одновременно и минус, т.к. достаточно сложно собирать данные о тестах из коробки

• нет очевидных встроенных решений от других фреймворков, например, playwright на python не содержит в себе сравнение скриншотов и прочие полезные ассерты, хотя на JS они есть по умолчанию

• нужно контролировать, какой инструмент за что отвечает, и чётко понимать, как их «дружить» между собой и развивать

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

Независимо от того, какой стек вы для себя выберете, есть набор пожеланий, которые актуальны на текущий момент (2023 год):

• ориентируйтесь на потребности бизнеса. Так вы поймёте объём доступных ресурсов, чтобы начать автоматизацию на проекте

• отталкивайтесь от стека на проекте, лучше иметь бОльшую экспертизу со стороны братьев наших разработчиков ?

• используйте библиотеки, они помогают компенсировать недостатки фреймворка:

  • чтобы не придумывать велосипед

  • если простым решением не обойтись

  • когда свой временный костыль превращается в полноценный поддерживаемый продукт, который поддерживать не очень хочется (особенно, если сервис для работы является сторонним)

• по возможности не используйте Selenium и всё, что с ним связано. Я вижу эту экосистему немного устаревшей, которая работает медленно и не всегда стабильно. Бывают случаи, когда нет другого выбора, например, сейчас я пишу Desktop тесты на Windows и драйвер работает на базе Selenium

• мыслите критически: проводите ресёрчи, сравнения, считайте время на внедрение инструментов, и только после принимайте решения

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

А ещё подписывайтесь на мой канал в Telegram – https://t.me/qaa_spells, публикую интересную информацию про автоматизацию тестирования на всех слоях, не только про e2e. Уже на подходе серия постов про автоматизацию Desktop-приложений, надеюсь, будет интересно ?