Розділювальні модульні тести та інтеграційні тести в Go

Чи існує встановлена ​​найкраща практика розділення модульних тестів та інтеграційних тестів у GoLang (засвідчити)? У мене є поєднання модульних тестів (які не покладаються на будь-які зовнішні ресурси і, отже, працюють дуже швидко) та інтеграційних тестів (які покладаються на будь-які зовнішні ресурси і, отже, працюють повільніше). Отже, я хочу мати можливість контролювати, включати чи ні тести інтеграції, коли я кажу go test.

Здається, найбільш прямим методом є визначення -інтегруючого прапора в основному:

var runIntegrationTests = flag.Bool("integration", false
    , "Run the integration tests (in addition to the unit tests)")

А потім додати оператор if у верхню частину кожного тесту інтеграції:

if !*runIntegrationTests {
    this.T().Skip("To run this test, use: go test -integration")
}

Це найкраще, що я можу зробити? Я шукав документацію для свідчень, щоб перевірити, чи існує, можливо, конвенція про іменування чи щось таке, що робить це для мене, але нічого не знайшов. Я щось пропускаю?

@ Ainar-G пропонує кілька чудових шаблонів для розділення тестів.

Цей набір практик Go від SoundCloud рекомендує використовувати теги збірки ( описані в розділі "Обмеження збірки" пакету збірки ) для вибору тестів для запуску:

Напишіть інтеграційний_тест.go і додайте йому тег побудови інтеграції. Визначте (глобальні) прапори для таких речей, як адреси послуг та підключення рядків, і використовуйте їх у своїх тестах.

// +build integration

var fooAddr = flag.String(...)

func TestToo(t *testing.T) {
    f, err := foo.Connect(*fooAddr)
    // ...
}

тест go приймає мітки побудови так само, як go build, так що ви можете зателефонувати go test -tags=integration. Він також синтезує основний пакет, який викликає flag.Parse, тому всі заявлені та видимі прапори будуть оброблені та доступні для ваших тестів.

Як подібний варіант, ви також можете запустити тести інтеграції за замовчуванням, використовуючи умову збірки // +build !unit, а потім вимкнути їх на вимогу, запустивши go test -tags=unit.

Коментарі @adamc:

Для всіх, хто намагається використовувати теги побудови, важливо, щоб // +build testкоментар був першим рядком у вашому файлі, і щоб ви додали порожній рядок після коментаря, інакше -tagsкоманда буде ігнорувати директиву.

Крім того, тег, використаний у коментарі до збірки, не може мати тире, хоча допускається підкреслення. Наприклад, // +build unit-testsне буде працювати, тоді як // +build unit_testsбуде.

Щоб детально розказати про свій коментар до чудової відповіді @ Ainar-G, протягом останнього року я використовував поєднання -shortз Integrationконвенцією іменування, щоб досягти найкращого з обох світів.

Unit і Integration перевіряють гармонію в одному файлі

Побудувати прапори раніше змусили мене кілька файлів ( services_test.go, services_integration_test.goі т.д.).

Натомість візьміть наведений нижче приклад, де перші два - це модульні тести, а в кінці я маю інтеграційний тест:

package services

import "testing"

func TestServiceFunc(t *testing.T) {
    t.Parallel()
    ...
}

func TestInvalidServiceFunc3(t *testing.T) {
    t.Parallel()
    ...
}

func TestPostgresVersionIntegration(t *testing.T) {
    if testing.Short() {
        t.Skip("skipping integration test")
    }
    ...
}

Зверніть увагу, що останній тест має узгодження:

1. використання Integrationв назві тесту.
2. перевірка, чи працює за -shortдирективою прапора.

В основному, специфікація говорить: "пишіть усі тести нормально. Якщо це довготривалі тести або інтеграційні тести, дотримуйтесь цієї угоди про іменування та перевірте, -shortчи приємні ваші друзі."

Запускати лише модульні тести:

go test -v -short

це надає вам гарний набір повідомлень, таких як:

=== RUN   TestPostgresVersionIntegration
--- SKIP: TestPostgresVersionIntegration (0.00s)
        service_test.go:138: skipping integration test

Запустіть лише інтеграційні тести:

go test -run Integration

Тут запускаються лише тести інтеграції. Корисно для випробування димних канарок на виробництві.

Очевидно, що недоліком цього підходу є те, що якщо хтось запускає go testбез -shortпрапора, він за замовчуванням запускатиме всі тести - модульні та інтеграційні тести.

Насправді, якщо ваш проект є достатньо великим, щоб мати модульні та інтеграційні тести, то ви, швидше за все, використовуєте Makefileде ви можете використовувати прості директиви для використання go test -shortв ньому. Або просто вставте його у свій README.mdфайл і назвіть день.

Я бачу три можливі рішення. Перший - використовувати короткий режим для модульних тестів. Отже, ви б використовували go test -shortз модульними тестами і те саме, але без -shortпрапора, щоб також запускати свої тести інтеграції. Стандартна бібліотека використовує короткий режим, щоб або пропустити тривалі тести, або зробити їх швидшими, надаючи простіші дані.

Другий - використовувати конвенцію та викликати свої тести TestUnitFooабо, TestIntegrationFooа потім використовувати -runпрапор тестування, щоб позначити, які тести запускати. Отже, ви могли б використовувати go test -run 'Unit'для модульних тестів та go test -run 'Integration'для інтеграційних тестів.

Третій варіант - використовувати змінну середовища та отримати її у налаштуваннях тестів за допомогою os.Getenv. Тоді ви використовували б просто go testдля модульних тестів та FOO_TEST_INTEGRATION=true go testдля інтеграційних тестів.

Я особисто віддав би перевагу -shortрішенню, оскільки воно простіше і використовується в стандартній бібліотеці, тому, схоже, це фактичний спосіб розділення / спрощення тривалих тестів. Але рішення -runand та os.Getenvпропонують більшу гнучкість (також потрібна більша обережність, оскільки задіяні регулярні вирази -run).

Нещодавно я намагався знайти рішення для того ж. Це були мої критерії:

• Рішення повинно бути універсальним
• Немає окремого пакету для інтеграційних тестів
• Розділення повинно бути повним (я повинен мати можливість запускати лише інтеграційні тести )
• Немає спеціальної норми іменування для інтеграційних тестів
• Він повинен добре працювати без додаткових інструментів

Вищезазначені рішення (спеціальний прапор, спеціальний тег збірки, змінні середовища) насправді не задовольняли всім вищезазначеним критеріям, тому після невеликого копання та гри я придумав це рішення:

package main

import (
    "flag"
    "regexp"
    "testing"
)

func TestIntegration(t *testing.T) {
    if m := flag.Lookup("test.run").Value.String(); m == "" || !regexp.MustCompile(m).MatchString(t.Name()) {
        t.Skip("skipping as execution was not requested explicitly using go test -run")
    }

    t.Parallel()

    t.Run("HelloWorld", testHelloWorld)
    t.Run("SayHello", testSayHello)
}

Реалізація проста і мінімальна. Хоча це вимагає простої конвенції для тестів, але вона менш схильна до помилок. Подальшим вдосконаленням може бути експорт коду у допоміжну функцію.

Використання

Запустіть інтеграційні тести лише для всіх пакетів проекту:

go test -v ./... -run ^TestIntegration$

Запустіть усі тести ( регулярні та інтеграційні):

go test -v ./... -run .\*

Запускайте лише регулярні тести:

go test -v ./...

Це рішення добре працює без інструментів, але Makefile або деякі псевдоніми можуть полегшити користувачеві. Він також може бути легко інтегрований в будь-яку IDE, що підтримує запущені Go-тести.

Повний приклад можна знайти тут: https://github.com/sagikazarmark/modern-go-application