Всем привет! С вами снова я, Иван Шевелёв, 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‑приложений, надеюсь, будет интересно ????