Привет! Меня зовут Антон, я ведущий инженер по тестированию в Ozon: занимаюсь созданием и поддержкой end-to-end Go-тестов бэкенда для QA.
Мы довольно долго писали тесты в основном на Python. Go – молодой язык, и популярных устоявшихся инструментов у него пока немного. В Python есть pytest, в Java – JUnit и TestNG, в Go – пока что весьма свободно.
Однажды, в очередной раз переписав группу старых Python-тестов, я решил, что надо что-то менять. Эта мысль в итоге привела меня к созданию нашей собственной опенсорс-библиотеки – с поддержкой Allure без перегрузки интерфейса, инфраструктурой для хранения тестов как в одних репозиториях с сервисами, так и в отдельных, репортами в Slack и разными другими штуками.
Почему мы всё-таки решили создать своё решение, с какими сложностями пришлось разбираться в процессе и как это может пригодиться вам для тестов на Go, я расскажу в этой и следующих статьях. Сегодня – об интеграции с Allure.
Для контекста: Go в Ozon
Большая часть сервисов в Ozon написана на Go, и со временем их количество только растёт.
Профит от Go в сервисах:
инфраструктура: относительно лёгкий докер, отлаженные джобы в GitLab CI для запуска интеграционных и юнит-тестов, линтеринг и код-ревью;
пакетная система на Git-репозиториях: не нужно забивать себе голову хранением и импортом вспомогательных библиотек; удобная система версионирования, основанная на Git-тегах;
относительно низкий порог входа: можно нанимать людей и доучивать их до нужного уровня в Go – довольно легко и
почтибезболезненно.
Всё это на руку нам в E2E-тестах: можно поднимать вспомогательные сервисы, писать библиотеки и службы – и использовать для этого инструменты разработчиков.
Вот только потенциал этот мы использовали не в полной мере: разработку вели на Go, а тесты писали на Python. Это был не всегда удобный, но привычный сценарий для E2E-тестирования на фоне небольшого числа готовых инструментов, которые предоставлял язык на тот момент.
Кроме того, хотелось достичь большего взаимопонимания между QA-специалистами и разработчиками, вовлекая последних в поддержку и развитие инструментов тестирования: с переходом QA-специалистов на Go проблема решается автоматически.
Первым делом: поддержка Allure
Итак, мы задались вопросом об альтернативе Python для тестирования Go-бэкенда.
Первый шаг – сформулировать требования, чего мы хотим от альтернативного инструментария.
Тесты должны писаться легко и быстро (а значит, быть недорогими в поддержке). Инструменты должны быть простыми и понятными для людей из разных команд с разным бэкграундом.
Но главное – поддержка Allure. Мы в Ozon активно его используем для сбора статистики и аналитики по тестам.
Изучив опыт коллег (привет, Vivid Money и Lamoda тут на Хабре) и проведя исследование, я обнаружил следующее:
официального решения Allure для Go на тот момент не существовало;
провайдеры есть (например, dailymotion/allure-go), но мне решительно не нравился их интерфейс, или они давно не обновлялись, как будто их перестали поддерживать (GabbyyLS/allure-go-common);
фреймворков тестирования не так много, самым перспективным выглядел Testify.
Ну что ж, тогда напишем свой провайдер для Allure.
Нам потребуется:
пробрасывать Allure-отчёты;
компоновать тесты;
запускать тесты.
Была надежда, что компоновку и запуск удастся сделать на Testify, но выяснилось, что тот не поддерживает плагины. Окей, напишем сами.
Так и появился наш опенсорс-проект Allure-Go.
Покажу несколько примеров его использования.
Что именно делает Allure-Go
Во-первых, как и Testify, наша библиотека позволяет организовывать тесты в тестовые классы структуры. Это делает код тестов понятнее и помогает явно выделять тест-комплекты, использовать Before и After-хуки. При этом сохраняется возможность более привычного для Go написания тестов как функций (также с использованием этих хуков).
Пример тестовой структуры:
type SuiteStruct struct {
suite.Suite
}
func (s *SuiteStruct) Test1() {
}
func (s *SuiteStruct) Test2() {
}
func TestRun(t *testing.T) {
runner.RunSuite(t, new(SuiteStruct))
}Пример теста-функции:
func TestSampleDemo(t *testing.T) {
r := runner.NewTestRunner(t)
r.WithBeforeEach(func(t *provider.T) {})
r.WithAfterEach(func(t *provider.T) {})
r.Run("My test 1", func(t *provider.T) {})
r.Run("My test 2", func(t *provider.T) {})
r.Run("My test 3", func(t *provider.T) {})
}Кроме того, Allure-Go предоставляет разные возможности для работы с шагами и Allure-лейблами. Интерфейс мы постарались сделать максимально лаконичным и user-friendly, прокинули через обёртки provider.T и suite.Suite.
Пример простого теста с вложенными шагами:
type StepTreeDemoSuite struct {
suite.Suite
}
func (s *StepTreeDemoSuite) TestInnerSteps() {
s.Epic("Demo")
s.Feature("Inner Steps")
s.Title("Simple Nesting")
s.Description(`
Step A is parent step for Step B and Step C
Call order will be saved in allure report
A -> (B, C)`)
s.Tags("Steps", "Nesting")
s.WithNewStep("Step A", func() {
s.NewStep("Step B")
s.NewStep("Step C")
})
}Ответ от Allure:
Важно: не перегрузить интерфейс
Особое внимание мы уделили тому, чтобы не перегрузить интерфейс вложенными вызовами.
Давайте сравним с dailymotion:
func TestNewTest(t *testing.T) {
allure.Test(
t,
allure.Description("New Test Description"),
allure.Action(func() {
allure.Step(
allure.Description("Step description"),
allure.Action(func() {
}))
}))
}То же самое в Allure-Go:
type SuiteStruct struct {
suite.Suite
}
func (s *SuiteStruct) TestNewTest() {
s.Description("New Test Description")
s.WithNewStep("Step description", func() {
})
}Кажется, стало лаконичнее.
Что мы получили
За полгода в продакшене — 0 проблем с заливкой отчётов, минимальный порог вхождения. Как следствие, коллеги стали интересоваться решением — на сегодняшний день втянулось и переехало более 30 команд в Ozon.
Прямо сейчас Allure-Go умеет следующее:
интегрировать Allure в Go-тесты (поддерживает шаги и аттачи, предлагает лаконичный интерфейс);
собирать тесты в сьюты;
запускать тесты в Go.
Планы:
зарелизить нашу библиотеку в официальный репозиторий Allure (Qameta Software);
добавить новые фичи: асинхронные степы через конструкцию запуска goroutine; обёртка ассертов в шаги (на базе ассертов Testify), прокидывание интерфейсов для упрощения расширения и другие.
Библиотека пережила три рефакторинга, сменила два репозитория и активно развивается. Система репортов обеспечивает графиками и статистикой более 40 сервисов. Основываясь на положительных отзывах, нашу библиотеку добавили в конвенцию для Go-тестов как рекомендованную к использованию.
Главный результат, на мой взгляд: мы сделали ещё один шаг в сторону реальности, в которой Dev и QA говорят на одном языке. Разработчики помогают с поддержкой и развитием тестов, тестировщики шире и глубже ориентируются в кодовой базе.
В следующих эпизодах поговорим об инфраструктуре, репортах и безопасности. Оставайтесь с нами!
Короче, встречайте
Allure-Go на GitHub. Надеюсь, будет полезно. Ждём ваших пулл-реквестов.
