Какие считаешь тесты нужно писать?

Мой подход к тестированию в Go проектах

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

1. Юнит-тесты (Unit Tests) — фундамент качества

Юнит-тесты проверяют отдельные функции, методы или небольшие модули в изоляции. В Go они особенно важны благодаря встроенному фреймворку testing.

// Пример юнит-теста для функции-валидатора
func TestValidateEmail(t *testing.T) {
    tests := []struct {
        name     string
        email    string
        expected bool
    }{
        {"valid email", "test@example.com", true},
        {"missing @", "testexample.com", false},
        {"invalid domain", "test@.com", false},
        {"empty string", "", false},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            result := ValidateEmail(tt.email)
            if result != tt.expected {
                t.Errorf("ValidateEmail(%q) = %v, want %v", 
                    tt.email, result, tt.expected)
            }
        })
    }
}

Ключевые принципы юнит-тестирования:

• Тестируем одну ответственность за раз
• Используем табличные тесты (table-driven tests) для покрытия кейсов
• Мокаем внешние зависимости через интерфейсы
• Достигаем покрытия критических путей >80%
• Тесты должны быть быстрыми (<100мс на весь suite)

2. Интеграционные тесты (Integration Tests)

Интеграционные тесты проверяют взаимодействие между компонентами: базой данных, внешними API, файловой системой.

// Пример интеграционного теста с тестовой БД
func TestUserRepository_Create(t *testing.T) {
    // Поднимаем тестовую БД
    db, cleanup := setupTestDB(t)
    defer cleanup()
    
    repo := NewUserRepository(db)
    user := &User{Name: "John", Email: "john@test.com"}
    
    err := repo.Create(context.Background(), user)
    if err != nil {
        t.Fatalf("Create failed: %v", err)
    }
    
    // Проверяем, что данные действительно сохранены
    retrieved, err := repo.FindByID(context.Background(), user.ID)
    if err != nil {
        t.Fatalf("FindByID failed: %v", err)
    }
    
    if retrieved.Email != user.Email {
        t.Errorf("Expected email %s, got %s", user.Email, retrieved.Email)
    }
}

3. End-to-End (E2E) тесты

E2E-тесты имитируют поведение реального пользователя, проверяя полный поток работы системы. В Go для этого часто используют testcontainers или специализированные фреймворки.

// Пример E2E теста для HTTP API
func TestUserRegistrationFlow(t *testing.T) {
    // Запускаем всё приложение в тестовом режиме
    app := startTestApplication(t)
    defer app.Shutdown()
    
    client := app.TestClient()
    
    // Регистрируем пользователя
    resp, err := client.Post("/api/register", 
        `{"email":"test@user.com","password":"secure123"}`)
    assert.NoError(t, err)
    assert.Equal(t, http.StatusCreated, resp.StatusCode)
    
    // Логинимся
    resp, err = client.Post("/api/login",
        `{"email":"test@user.com","password":"secure123"}`)
    assert.NoError(t, err)
    assert.Equal(t, http.StatusOK, resp.StatusCode)
    
    // Проверяем доступ к защищенному роуту
    token := extractToken(resp)
    resp, err = client.GetWithToken("/api/profile", token)
    assert.NoError(t, err)
    assert.Equal(t, http.StatusOK, resp.StatusCode)
}

4. Нагрузочные и тесты производительности

Go имеет встроенную поддержку бенчмарков, что идеально для тестирования производительности:

func BenchmarkHashPassword(b *testing.B) {
    password := "mySuperSecretPassword123"
    for i := 0; i < b.N; i++ {
        HashPassword(password)
    }
}

5. Fuzz-тестирование

Начиная с Go 1.18, фаззинг стал первой-class citizen. Это отличный способ найти краевые случаи:

func FuzzParseQuery(f *testing.F) {
    f.Add("name=John&age=30")
    f.Add("search=hello+world&filter=active")
    
    f.Fuzz(func(t *testing.T, query string) {
        params, err := ParseQuery(query)
        if err != nil {
            // Проверяем, что при ошибке возвращаем nil map
            if params != nil {
                t.Errorf("params should be nil on error")
            }
            return
        }
        
        // Проверяем инварианты
        for key, values := range params {
            if key == "" {
                t.Errorf("empty key in params")
            }
            if len(values) == 0 {
                t.Errorf("no values for key %s", key)
            }
        }
    })
}

6. Мой практический стек тестирования

В реальных проектах я комбинирую:

• testing + testify/assert — для удобных ассертов
• gomock или mockery — для генерации моков
• testcontainers-go — для поднятия зависимостей в Docker
• ginkgo/gomega — для BDD в сложных доменах
• go-sqlmock — для мокинга SQL-запросов
• httptest — для тестирования HTTP-обработчиков
• race detector — всегда запускаю с -race флагом

Стратегия внедрения тестов

1. Сначала юниты для новой функциональности
2. Интеграционные тесты для критических путей
3. E2E тесты для ключевых user journeys
4. Регрессионные тесты для исправленных багов
5. Периодические ревью покрытия тестов

Важный принцип: тесты должны быть maintainable. Плохо написанный тест хуже, чем отсутствие теста, потому что создает ложное чувство безопасности и становится обузой для разработки. В Go я особенно слежу за тем, чтобы тесты не становились хрупкими, используя четкие интерфейсы и dependency injection.

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