Пишешь ли тесты для других микросервисов

Мой подход к написанию тестов для других микросервисов

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

Что я обычно тестирую в контексте чужих микросервисов:

1. Интеграционные тесты API-контрактов — проверяю, что мой сервис корректно формирует запросы и обрабатывает ответы в соответствии с согласованными контрактами:

func TestOrderServiceIntegration(t *testing.T) {
    // Тестируем взаимодействие с сервисом заказов
    client := NewOrderServiceClient(mockServer.URL)
    
    req := &OrderRequest{UserID: "123", Items: []string{"item1"}}
    resp, err := client.CreateOrder(context.Background(), req)
    
    require.NoError(t, err)
    assert.Equal(t, "pending", resp.Status)
    assert.NotEmpty(t, resp.OrderID)
}

1. Юнит-тесты клиентских библиотек — покрываю тестами всю логику клиентов для внешних сервисов:

func TestPaymentClient_ProcessPayment(t *testing.T) {
    mockHTTP := NewMockHTTPClient()
    client := NewPaymentClient(mockHTTP)
    
    // Настраиваем мок для определенного сценария
    mockHTTP.SetResponse(`{"status": "success", "transaction_id": "txn_123"}`, 200)
    
    result, err := client.ProcessPayment(PaymentRequest{Amount: 100})
    
    assert.NoError(t, err)
    assert.Equal(t, "success", result.Status)
}

1. Контрактные тесты (Pact-тестирование) — для критически важных интеграций использую Pact или аналогичные инструменты для проверки совместимости API:

// Пример контрактного теста с Pact
func TestUserServiceContract(t *testing.T) {
    pact := setupPactTest("MyService", "UserService")
    defer pact.Teardown()
    
    pact.
        AddInteraction().
        Given("user exists").
        UponReceiving("request for user details").
        WithRequest("GET", "/users/123").
        WillRespondWith(200, map[string]string{
            "Content-Type": "application/json",
        }, `{"id": "123", "name": "John"}`)
    
    // Тестируем клиент с использованием pact мок1сервера
    client := NewUserClient(pact.Server.URL)
    user, err := client.GetUser("123")
    
    assert.NoError(t, err)
    assert.Equal(t, "John", user.Name)
}

Что я НЕ тестирую в чужих микросервисах:

• Внутреннюю бизнес-логику других сервисов — это ответственность их команд
• Реальные вызовы к production-сервисам в автоматических тестах
• Сценарии, которые уже покрыты тестами команды-владельца сервиса

Ключевые принципы моего подхода:

Принцип ограниченной ответственности — я тестирую только то, за что отвечает мой сервис:

• Корректность формирования запросов
• Обработку всех возможных ответов (успех, ошибки, таймауты)
• Соответствие согласованным контрактам

Использование моков и стабов — для изоляции тестов:

// Интерфейс для легкого мокирования
type InventoryServiceClient interface {
    CheckAvailability(ctx context.Context, itemID string) (bool, error)
    ReserveItem(ctx context.Context, itemID string, quantity int) error
}

// Мок для тестов
type MockInventoryClient struct {
    CheckAvailabilityFunc func(ctx context.Context, itemID string) (bool, error)
}

func (m *MockInventoryClient) CheckAvailability(ctx context.Context, itemID string) (bool, error) {
    return m.CheckAvailabilityFunc(ctx, itemID)
}

Тестирование граничных случаев и ошибок:

• Таймауты сетевых вызовов
• Некорректные ответы (невалидный JSON, неожиданные статус-коды)
• Отказы сервисов (circuit breaker, retry logic)

Практические аспекты:

1. Согласование контрактов — перед написанием тестов я участвую в обсуждении и утверждении API-контрактов между сервисами
2. Общие тестовые утилиты — часто разрабатываю shared-библиотеки для тестирования, которые могут использовать несколько команд
3. Тестирование в CI/CD — настраиваю различные уровни тестов:
   • Быстрые юнит-тесты с моками (запускаются на каждый коммит)
   • Интеграционные тесты с тестовыми стендами (запускаются перед мержем)
   • Контрактные тесты (запускаются при изменении API)

Баланс и pragmatism:

Я избегаю over-engineering в тестировании внешних сервисов. Критерии для принятия решения о глубине тестирования:

• Критичность интеграции для бизнес-логики
• Частота изменений в API
• История надежности внешнего сервиса
• Сложность взаимодействия

Золотое правило: тестировать достаточно, чтобы быть уверенным в надежности интеграции, но не брать на себя ответственность за чужой код. Лучшая стратегия — это сочетание контрактного тестирования на границах сервисов и качественных юнит-тестов внутри своего кода с правильным использованием dependency injection и мокирования.