Как стать автором
Обновить

Как и зачем мы написали 5000 интеграционных тестов за пару часов

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров15K
Всего голосов 21: ↑20 и ↓1+22
Комментарии12

Комментарии 12

На пример итоговых шаблонов и сценариев было бы интересно взглянуть

Мы пишем на Go, у нас принят формат табличных тестов. Шаблон выглядит достаточно просто - это каркас табличного теста, в который подставляется набор тестовых сценариев после этапа сбора данных

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

Выглядит это примерно вот так:

// собираем тестовый сценарий 
func {{ testScenarioName }}(t *testing.T) { testCategory := &domain.Category{ Name:     "{{ $testScenario.Category.Name }}", }
testdata := []struct{
    name              string
    Category          *domain.Category
    expectedFields    []*domain.Field
}{
// собираем тест-кейсы. Каждый тест-кейс - это ожидаемый набор полей от валидатора
{{- range .Cases }}
    {
        name:              "{{ testCaseName }}",
        Category:     testCategory,
        expectedFields: []*domain.Field{
        {{- range .ExpectedFields }}
            {
                Data: &domain.FieldData{
                    Label:         "{{ .Data.Label }}",
                    Widget:        &domain.Widget{
                        Type: "{{ .Data.Widget.Type }}",
                        Config: `{{ .Data.Widget.Config | escapeBackQuotes }}`,
                    },
                    IsRequired:    {{ .Data.IsRequired }},
                },
            },
        {{- end }}
    },
{{- end }}

// инициализируем клиент валидатора для запросов реального текущего состояния
validationClient := out.NewValidationClient("master")
testComparator := test_comparator.New()
for _, data := range testdata {
    t.Run(data.name, func(t *testing.T) {
        // получаем актуальный список полей после внесенных изменений от контент-менеджера
        actual, err := validationClient.GetForm(context.Background(), data.Category)
        if !assert.NoError(t, err) {
            return
        }

        // сравниваем набор ожидаемых полей с теми, что получили в результате запроса к изменениями контент-менеджера
        assertions := make([]test_comparator.Assertion, 0)
        assertions = append(assertions, testComparator.CompareFields(actual.Fields, data.expectedFields)...)
        
        for _, assertion := range assertions {
            assertion(t)
        }
    })
}
}

Как реализован генератор тестов? Вы какое-то open-source решение использовали, или свои скрипты разрабатывали?

Сам механизм мы подробно разберем в следующей статье - разрабатывали отдельный сервис для генерации и запуска тестов, open-source решения не использовали.

Могу печатать со скоростью 2000 символов в минуту, такой бред получается...

А можете показать пример сгенерированного теста, который смог найти реальный баг?

Пример теста показать, увы, не могу.
Но из недавних багов ловили то, что характеристика была выведена в нескольких категориях, чего быть не должно: условно "Тип запчасти" появился в публикации кроссовок. Реальный пример был не такой яркий, но не менее важный для нас.

А зачем вообще тестировать каждую такую форму? Покрыть тестами всякие простые и сложные сочетания компонентов в форме - понятно. Добавить валидацию созданных форм - орфографию, какие-то еще проверки - понятно. Но зачем созданные формы потом тестировать то, что в них может ломаться?

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

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

Расскажите пожалуйста подробнее про генератор. Вы пишите что генерируете интеграционные тесты, а могли бы уточнить что именно в это понятие вкладываете или может пример какой, кажется что вы делаете запрос на бек и сравниваете json. Или что-то ещё? Хочется больше инфы, так как тема очень интересная и нетривиальная)

И правильно я понял, что ваша команда занимается только проверкой админки? Т.е. вы генерируете тесты для админки и валидатора?

Помогите разобраться в двух моментах:

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

По итогу, если я правильно поняла, тестируют контент-менеджеры и генератор. Получается проблемы с отсутствием qa-экспертизы при тестировании осталась не закрыта? А контент-менеджеры тестируют без инструкций? что они тогда тестируют?

Не хватает примеров по работе генератора потому что без примеров непонятно какую ценность он несёт и в чём вы выиграли кроме как уменьшения во времени. Потому что уменьшение во времени можно ввести за счёт снижения качества.

А на сам генератор теперь тесты не нужны?

Нужны) На генератор также пишем тесты, как и на любой свой сервис

Зарегистрируйтесь на Хабре, чтобы оставить комментарий