Какие подходы используются для тестирования кода, взаимодействующего с базой данных?

А, ну вот, опять про тестирование с этой ёбнутой базой данных! Слушай, тут, блядь, как обычно, три пути, и все они ведут в пизду, но по-разному. Выбирай, на чём подорваться.

1. Настоящая база, но в банке (Testcontainers)

Представь, ты для каждого теста, как дурак, запускаешь целый докер-контейнер с постгресом. Это как приглашать на чай экскаватор — мощно, но дохуя мороки.

• Чем хорошо, блядь:
  • Всё по-чесноку: Тестируешься на той же самой хуйне, что и в бою. Никаких сюрпризов.
  • Чистота, ёпта: Каждый тест начинает с девственной базы. Никаких чужих соплей.
• Чем пиздецово:
  • Медленно, как черепаха в сиропе: Ждать, пока контейнер встанет, — это отдельная медитация.
  • Зависишь от докера: Нет докера — нихуя не протестируешь.

// Вот так это выглядит, сука
func TestUserRepository_WithPostgres(t *testing.T) {
    ctx := context.Background()
    req := testcontainers.ContainerRequest{
        Image:        "postgres:13-alpine", // Вот он, красавец
        ExposedPorts: []string{"5432/tcp"},
        Env: map[string]string{"POSTGRES_PASSWORD": "password"},
    }
    pgContainer, _ := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{...})
    defer pgContainer.Terminate(ctx) // После теста — в утиль

    // ... дальше подключаешься и тестишь как с настоящей...
}

2. Показательные выступления (Моки)

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

• Плюсы, ёбана:
  • Быстрее ветра: Всё летает в оперативке, никаких тормозов.
  • Король положения: Заставишь мок вернуть любую хуйню или упасть с ошибкой — полный контроль.
• Минусы, пиздец:
  • SQL не проверяется вообще: Ты можешь написать в коде SELECT * FROM users WHERE хуй = 1, и мок это проглотит, а в продакшене всё ебнется.
  • Хрупкое говно: Изменил сигнатуру метода в реальном коде — иди и переписывай все моки, блядь.

// Пример с testify/mock — классика жанра
type MockUserRepository struct {
    mock.Mock // Вот эта штука всё и умеет
}

func (m *MockUserRepository) GetUserByID(id int) (*User, error) {
    args := m.Called(id) // "Меня вызвали с такими аргументами"
    return args.Get(0).(*User), args.Error(1) // А я вот это верну
}

func TestUserService(t *testing.T) {
    mockRepo := new(MockUserRepository)
    user := &User{ID: 1, Name: "Test"}
    // Настраиваем спектакль: "Когда спросят юзера с ID=1, верни вот этого"
    mockRepo.On("GetUserByID", 1).Return(user, nil)

    service := NewUserService(mockRepo)
    // ... и тестируем сервис, который думает, что ходит в базу...
}

3. База-пустышка (In-memory, типа SQLite)

Компромисс, ёпта. Берёшь SQLite, запускаешь её в памяти и гоняешь на ней тесты. Быстро и запросы настоящие.

• Чем прикольно:
  • Шустро: Быстрее контейнеров, не надо ждать.
  • SQL работает: Запросы-то выполняются, синтаксис проверяется.
• Чем опасно:
  • Диалекты, блядь: SQLite — это не PostgreSQL. То, что работает на SQLite, может нахуй послать тебя на продакшене с его постгресом. Идеальный способ получить ложное чувство безопасности.

Так как же жить-то, ёпта?

• Двумя руками, блядь: Моки — для быстрых юнит-тестов твоей бизнес-логики (сервисов, хендлеров). Testcontainers — для медленных, но честных интеграционных тестов, которые проверяют, что твой репозиторий вообще умеет разговаривать с реальной базой.
• Дели на слои: Всю работу с базой засунь в отдельный слой (репозиторий). Его будет легко замокать для всего, что выше.
• Убирай за собой: В интеграционных тестах оборачивай всё в транзакцию и делай ROLLBACK в конце. Чтобы тесты не насрали друг другу в базу и не начали ругаться.