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