Недавно на собеседовании меня спросили:

Как ты выбираешь язык программирования для нового automation framework?

И я ответил… сильно хуже, чем мог 😄

Начал рассказывать, как на одном из проектов перед стартом UI-автоматизации сравнивал Cypress, Selenium и Playwright. Почему выбрал Playwright, какие критерии использовал и так далее.

И только выйдя с собеседования вспомнил две вещи.

Во-первых, backend и API-автоматизация на проекте уже были написаны на Python. Что, конечно же, было одним из аргументов в пользу Python для нового фреймворка.

Во-вторых, я вспомнил алгоритм, которым вообще-то сам и пользуюсь при выборе стека.

Если сильно упростить, есть три базовых варианта: Язык backend-команды → API + UI automation. Язык frontend-команды → API + UI automation. Два языка → backend-язык для API, frontend-язык для UI.

Но это только отправная точка.

Дальше я смотрю на контекст проекта: + какой стек уже есть и кто будет поддерживать тесты; + какие компетенции есть внутри команды; + какие типы тестов нам действительно нужны; + насколько хорошо экосистема языка закрывает API, UI, integration и другие необходимые уровни; + как всё это будет жить в CI/CD; + и главное, какую проблему мы вообще пытаемся решить автоматизацией.

Потому что выбор между Python и TypeScript сам по себе не архитектурное решение.

Архитектурное решение - это выбрать стек, который подходит конкретной системе, команде и задачам качества, а не тот, на котором лично тебе удобнее писать тесты.

Самое смешное, что подробнее этот процесс я уже разбирал в статье про построение UI-автоматизации с нуля до CI (можете глянуть у меня в закрепе)

Но, конечно, именно в тот момент, когда нужно было рассказать об этом за две минуты, мозг решил временно удалить эту информацию из оперативной памяти 😄

Так что оставлю этот алгоритм здесь. Хотя бы чтобы на следующем собеседовании самому его не забыть.