Ответ
На моем последнем проекте по тестированию весь код, включая фреймворк для автотестов и вспомогательные скрипты, хранился в системе контроля версий Git. Основной репозиторий был размещен на GitLab (ранее использовал GitHub и Bitbucket).
Структура репозитория для автотестов была примерно такой:
qa-automation/
├── src/
│ ├── api/ # Модуль для API-тестов (использовали requests/pytest)
│ ├── ui/ # Модуль для UI-тестов (использовали Playwright)
│ ├── helpers/ # Вспомогательные классы (работа с БД, генерация данных)
│ └── config/ # Конфигурационные файлы
├── tests/
│ ├── test_suite_api/ # Наборы API-тестов
│ └── test_suite_ui/ # Наборы UI-тестов
├── test_data/ # Тестовые данные в JSON/CSV файлах
├── allure-results/ # Результаты прогонов для Allure Report (в .gitignore)
├── .gitlab-ci.yml # Конфигурация CI/CD пайплайна в GitLab
├── requirements.txt # Зависимости Python
└── README.md # Документация по запускуКлючевые практики работы:
- Мы следовали гибкой модели ветвления: создавали
feature/ветки для новой функциональности тестов, затем мержили вdevelop, а оттуда — вmain. - Каждый merge request проходил ревью кода от другого QA-автоматизатора или разработчика.
- В GitLab CI был настроен пайплайн, который запускал линтер, набор smoke-тестов и генерацию Allure-отчета при каждом пуше.
- Для хранения чувствительных данных (логины, токены, ключи API) использовались переменные окружения в настройках CI/CD, которые никогда не коммитились в репозиторий.
Ответ 18+ 🔞
А, ну это про гита и тесты! Ёпта, расскажу, как у нас на проекте всё было организовано, а то некоторые до сих пор код в папочке «Мои тесты» на рабочем столе хранят, ядрёна вошь.
Короче, вся наша движуха с автотестами — фреймворк, скрипты, конфиги — всё это жило в Git. Раньше баловались с GitHub и Bitbucket, но в итоге осели на GitLab, там CI/CD пайплайны настраивать — одно удовольствие, ей-богу.
Вот смотри, как репозиторий выглядел, чтоб ты понимал масштаб:
qa-automation/
├── src/
│ ├── api/ # Тут мы API долбили (requests + pytest, красота)
│ ├── ui/ # А тут браузеры ебали через Playwright
│ ├── helpers/ # Всякие утилитки: к БД подключиться, тестовые данные сгенерить
│ └── config/ # Конфигурационные файлы, без них никуда
├── tests/
│ ├── test_suite_api/ # Наборы этих самых API-тестов
│ └── test_suite_ui/ # Наборы UI-тестов, которые могли полчаса работать
├── test_data/ # Данные для тестов в JSON/CSV — овердохуища файлов
├── allure-results/ # Результаты прогонов для Allure (это в .gitignore, естественно)
├── .gitlab-ci.yml # Самое сердце — конфиг CI/CD пайплайна в GitLab
├── requirements.txt # Зависимости питона, чтобы всё поднялось
└── README.md # Инструкция, которую никто не читает, пока всё не сломаетсяА как мы работали, спросишь? Ну, правила были простые, но железные.
- Ветвились по гибкой модели, не абы как. Под каждую новую фичу тестов — своя ветка
feature/. Напилили, проверили — мержим вdevelop. А изdevelopуже, когда всё стабильно, вmainотправляем. Без этой дисциплины — пиздец и бардак, а не процесс. - Каждый merge request обязательно гоняли на ревью. Другой автоматизатор или, на худой конец, разработчик должен был глянуть код и сказать: «Вася, ты тут хуйню написал, поправь». Без этого ни один коммит не летел дальше. Доверия, блядь, ноль к самому себе.
- В GitLab CI был настроен пайплайн — просто песня. Ты пушишь код, а он сам: линтер прогонит, смоук-тесты запустит и Allure-отчёт тебе сгенерит. Красота!
- И самое главное — секреты. Пароли, токены, ключи от API — это святое. Никогда, слышишь, НИКОГДА не коммитилось в репозиторий. Всё это лежало в переменных окружениях в настройках CI/CD. Один раз один чувак закоммитил токен — так мы всем отделом ему мозг вынесли, ебать колотить. Больше он так не делал.
Вот так вот, нехитро, но зато надёжно. А то знаю я команды, где в общую папку на Google Drive код кидают — просто манда с ушами какая-то.