131. Онбординг в автотесты на Python

Вчера я организовал себе онбординг в автотесты на Python в рабочем проекте - расскажу кому это может пригодиться и как все прошло.

Кому будет полезно

Новичкам, кто хочет научиться делать автотесты на Python (популярные языки мало отличаются в этом плане - дальше в статье все расскажу)
Действующим специалистам в этой теме - если ты уже пишешь автотесты самостоятельно, то эта статья может быть особенно полезной
Менеджерам, которые хотят снизить нагрузку на ручных тестировщиков (автотесты работают намного быстрее, чем живые люди - это факт)
Всем желающим, кто умеет читать и нажимать на кнопки в этом нашем "айти"

Прежде чем начинать

Ключевые моменты, влияющие на успех при изучении автотестов:

Мотивация - если не хочется узнавать новое и учиться, можно закрывать статью
Отсутствие страхов: если страшно, если есть сомнения типа "а вдруг не получится", "а что если нужно уметь программировать", "да я не знаю математику", "да я не знаю Python" - лучше сразу закрыть статью, чтобы не страдать

Мой опыт в Python

В 2022 году я изучал Python в каком-то бесплатном мобильном приложении, потратил на это около 3-4 дней и не стал углубляться в детали, т.к. не использую этот язык в работе никогда, и вообще не использую его нигде.

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

Как я пришел к автотестам в рабочем проекте

Сначала я начал активно писать (генерировать) автотесты в iOS-приложении, и после пары сотен тестов на Swift поинтересовался у наших тестировщиков, как они пишут свои тесты.

Свои тесты я пишу почти целиком с использованием курсора, о котором я уже писал тут и тут, поэтому предложил поделиться опытом, чтобы упростить их работу.

Оказалось, что ребята не пользуются курсором, и вообще автотестам нужно учиться, а это небыстро и т.д.

Я решил разобраться в этой теме.

Шаг 1

Первым делом запросил доступ к репозиториям с автотестами. Репозиторий - место, где хранится код проекта. Например, тут список моих репозиториев в гитхабе.

Шаг 2

Дальше нужно их клонировать, т.е. скачать себе на комп - для этого я использую GitHub Desktop, но можно пользоваться любыми инструментами, которые вам нравятся, даже просто командами в терминале (я их не заучивал, поэтому не использую).

Шаг 3

Когда все загружено, осталось открыть проект в курсоре и приступать к делу - вот тут и начинается самое интересное и веселое.

Разбираемся вместе с курсором

Открываем проект в курсоре и что мы видим? Как всегда - список папок с файлами, и просто файлы.

Если в проекте есть документация, хотя бы README.md, нужно обязательно туда заглянуть - вдруг документ не забросили и поддерживают в актуальном состоянии. Примеры ридми-файлов: первый, второй, третий.

Поскольку я вообще не представлял, как все работает в этом проекте, то я сказал курсору:

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

Курсор подумал, что-то сделал, и через пару-тройку минут выдал ответ:

Я подготовил окружение и проверил запуск части тестов.

Что нужно установить/сделать:
Установить Python 3.11+.
Создать venv и поставить зависимости из requirements.txt (там свой PyPI-индекс, работает).
Создать /.env.local рядом с config.py с переменными: BASE_URL, USER_PASSWORD, TESTERDAV_PASSWORD.
Сгенерировать tests/_generated/actions.py.

Я уже выполнил:

Установил Python 3.11 через Homebrew.
Создал venv на 3.11, установил зависимости.
Сгенерировал tests/_generated/actions.py.
Скопировал .env в .env.local (для локального прогона; значения лучше заменить на корректные).
Запустил безопасный тест без авторизации: 3 passed, 1 deselected.
Тест с логином упал из‑за отсутствия валидных данных для логина (пустой токен).

Можно ли сразу писать и запускать тесты?

Да, если у вас установлен Python 3.11+ и заполнен /.env.local. Тесты без авторизации уже успешно проходят. Для тестов с авторизацией нужно корректно заполнить логин/пароль в /.env.local.

1-2 предложения о прогрессе:

Я собрал окружение на Python 3.11, поставил зависимости, сгенерировал actions и запустил тесты: без авторизации — успех, авторизационные падают из‑за отсутствия валидных учётных данных. Готов подключить реальные значения в .env.local и прогнать полный набор.

Знаю ли я про окружения в Python - совсем нет. Как их настраивать? Без понятия.

При этом у меня в GitHub Desktop отобразилось несколько сотен новых файлов, что меня немного напрягло, и я написал в курсор:

проверь список изменений, которые мы не закоммитили - нужно ли что-то из этого добавить в гитигнор, чтобы не ломать работу другим коллегам в этом репозитории? и нужно ли нам оставлять тесты, которые ты создал в @actions/ , или это были просто пробные тесты и их можно удалить? если можно удалить, сделай это

Ответ курсора через 20 секунд:

Проверил незакоммиченные изменения: изменены только .gitignore и README.md. Новых тестовых файлов я не создавал.
Добавил в .gitignore: /.venv/, **/__pycache__/, .DS_Store. Это исключит локальные артефакты macOS и Python, чтобы не мешали коллегам.
tests/_generated/actions.py уже игнорируется (правило /tests/_generated/* есть), оставляем как есть.
Про «пробные тесты» в tests/api/actions/: новых не добавлял — папка уже была в проекте; удалять нечего.
Итого:В гит добавлять больше ничего не нужно, кроме уже внесённого .gitignore и обновлённого README.md.
Тесты в @actions/ не мной созданы и удалять их не нужно.

Все новые файлы исчезли из списка в гите после обновления gitignore курсором, все четко ✅

Дальше я сказал курсору создать Makefile с командами для настройки проекта и запуска тестов, чтобы коллегам в будущем было проще все настроить одной командой на macOS/linux, и проверить эти команды на работоспособность.

Про Makefile я писал тут и тут.

Примерно через 25 минут, когда я сам проверил команды из Makefile и убедился, что все работает, я попросил курсор написать новый автотест по аналогии с существующими - он написал тест и запустил, все ок ✅

Обновляем документацию

Пишу курсору:

теперь обнови ридми, чтобы там было краткое и понятное объяснение как запускать тесты и через стандартные команды (pytest), и через make-команды, и приведи по одному примеру для каждого варианта запуска тестов

Он обновил ридми, я внес пару корректировок, а потом задал пару уточняющих вопросов про окружения в Python:

получается, что для запуска тестов через команду pytest не нужно предварительно активировать окружение? или я неправильно понял? если нужно активировать окружение, то прямо в примере запуска тестов с pytest напиши это. а то сейчас путаница возникает, как будто при использовании pytest не нужно делать предварительно source .venv/bin/activate

Ответ:

Я обновлю раздел в README, чтобы в примере для pytest явно сначала шёл source .venv/bin/activate, а альтернативный вариант без активации был выделен отдельно, чтобы не было путаницы. Затем вернусь с кратким резюме.

Уточнил формулировку в README:

Для обычного вызова pytest через оболочку нужно активировать окружение. В примере теперь явно:
сначала source .venv/bin/activate
затем pytest tests/... -q
Отдельной строкой оставил альтернативу без активации: ./.venv/bin/pytest ...

Так путаницы не будет: либо source + pytest, либо прямой вызов бинарника из .venv.

проверь, есть ли в проекте какой-то пример оформления тестов? или инструкция по написанию тестов? я хочу добавить такой раздел в ридми, чтобы проще было начинать работать новым членам команды

В результате в ридми появился разделы "Запуск тестов на macOS" и "Как писать тесты" ✅

Выводы по этому проекту

Я потратил около 30 минут на полную настройку проекта на своем ноуте, но в следующий раз другим ребятам (у которых macOS/linux) это можно будет сделать за пару минут, просто выполнив одну команду в терминале
Разобрался как запускать существующие тесты и увидел как они проходят/падают
Написал свой первый тест на Python за 1 запрос в курсоре

Что было дальше

Дальше я повторил все с самого начала во втором проекте с UI-тестами для сайта, и это заняло в сумме около полутора часов, потому что:

Долго разбирался с кредами для тестовых учетных записей (логины, пароли, адреса почты), в итоге все нашлось, спасибо коллегам
Сгенерировал неправильную автоматизацию в Makefile сначала

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

В общем, есть такой файл config.py, где есть строка с явным указанием названия файла с кредами, например:

load_dotenv(find_dotenv(filename=".env"), override=True)

Как я в этом разобрался?

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

Он запустил первый тест с авторизацией, тест упал, потом курсор за минуту нашел проблему и поправил ✅

Заключение

Я хотел показать, что нет необходимости предварительно учить язык программирования, или покупать и проходить курсы по "тестированию с нуля", или просто платить кому-то деньги за обучение новому в "айти", прежде чем начинать заниматься делом. Можно сразу начинать разбираться в рабочих задачах.

Хочется чему-то научиться илиразобраться в новой теме? Открываем бесплатные инструменты типа перплексити и просим составить план обучения. Есть еще российские аналоги, но я ими ни разу не пользовался, поэтому не могу ничего полезного сказать про них.

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

Боишься, что не получится? Я старался писать простым языком и делать акцент на том, что не нужно иметь опыт, чтобы его получить. Да, не нужен опыт работы, чтобы начать работать. Не нужно получать высшее образование, чтобы начать зарабатывать деньги.

У тебя все получится, главное взять на себя ответственность за свое обучение и терпеливо решать возникающие задачи (проблемы) 🚀