Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: Тестирование · Уровень: Middle+/Senior

## TL;DR
Интеграционные тесты проверяют код против **реальных** зависимостей (БД, брокеры, кэши), а не моков. `testcontainers-go` поднимает эти зависимости в Docker-контейнерах на лету: тест получает реальный Postgres/Redis/Kafka с динамическим портом, использует его и уничтожает контейнер по завершении — без ручного docker-compose и без общей «тестовой» БД. `TestMain(m *testing.M)` даёт единую точку setup/teardown на весь пакет (один контейнер на пакет — баланс скорости и изоляции). Медленные/требующие Docker тесты отделяют от unit-тестов через **build tags** (`//go:build integration`) или `testing.Short()`, чтобы `go test ./...` оставался быстрым, а интеграционные шли отдельным шагом CI. Изоляция между тестами — через отдельные схемы/БД/префиксы, транзакции с откатом или truncate.

## Теория

### Пирамида и место интеграционных тестов
- **Unit** — быстрые, без I/O, моки/fakes. Большинство.
- **Integration** — реальная зависимость, медленнее, требуют Docker. Проверяют то, что моки не могут: реальный SQL-диалект, миграции, сериализацию, транзакционную семантику, поведение драйвера.
- **E2E** — вся система. Мало, дорого.

Моки репозитория не поймают опечатку в SQL, неверный тип колонки, нарушение констрейнта, особенности изоляции транзакций — это ловит интеграционный тест против настоящей БД.

### testcontainers-go: базовый паттерн
```go
func setupPostgres(ctx context.Context, t *testing.T) (*pgxpool.Pool, func()) {
    req := testcontainers.ContainerRequest{
        Image:        "postgres:16-alpine",
        ExposedPorts: []string{"5432/tcp"},
        Env: map[string]string{
            "POSTGRES_PASSWORD": "test",
            "POSTGRES_DB":       "app",
        },
        WaitingFor: wait.ForListeningPort("5432/tcp").
            WithStartupTimeout(30 * time.Second),
    }
    container, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
        ContainerRequest: req,
        Started:          true,
    })
    require.NoError(t, err)

    host, _ := container.Host(ctx)
    port, _ := container.MappedPort(ctx, "5432")
    dsn := fmt.Sprintf("postgres://postgres:test@%s:%s/app?sslmode=disable", host, port.Port())

    pool, err := pgxpool.New(ctx, dsn)
    require.NoError(t, err)

    cleanup := func() {
        pool.Close()
        _ = container.Terminate(ctx)
    }
    return pool, cleanup
}
```
Ключевое:
- **Динамический порт.** Контейнер публикует случайный хостовый порт (`MappedPort`) — параллельные прогоны не конфликтуют, нет хардкода `localhost:5432`.
- **WaitingFor (wait strategy).** Контейнер «запущен» ≠ «готов принимать соединения». Postgres логирует «ready» дважды (init + restart). Используйте `wait.ForSQL`, `wait.ForLog(...).WithOccurrence(2)`, `wait.ForHTTP` — а не `time.Sleep`. Это главный источник флаки.
- **Модули.** Для популярных сервисов есть готовые: `modules/postgres`, `modules/redis`, `modules/kafka` — с корректными wait-стратегиями и хелперами (`postgres.RunContainer(...)`, `pgContainer.ConnectionString(...)`).
- **Ryuk (reaper).** testcontainers запускает контейнер-«сборщик мусора», который убивает забытые контейнеры даже при падении/kill теста. Можно отключить (`TESTCONTAINERS_RYUK_DISABLED=true`), но тогда сами отвечаете за уборку.

### TestMain: setup/teardown на пакет
Поднимать контейнер на каждый тест дорого. `TestMain` поднимает один раз на пакет:
```go
var testPool *pgxpool.Pool

func TestMain(m *testing.M) {
    ctx := context.Background()
    container, pool, err := startPostgres(ctx)
    if err != nil {
        log.Fatalf("setup: %v", err)
    }
    testPool = pool

    code := m.Run() // запускает все тесты пакета

    pool.Close()
    _ = container.Terminate(ctx)
    os.Exit(code) // ВАЖНО: код возврата из m.Run()
}
```
Нюансы `TestMain`:
- Если объявлен, тесты запускаются **только** через `m.Run()` — забыть его вызвать = тесты не выполнятся.
- `os.Exit(m.Run())` обходит `defer` — teardown пишите ДО `os.Exit` явно, либо оборачивайте в функцию с defer и передавайте код в `os.Exit`.
- Один на пакет. Для разной инфраструктуры — разбивайте на пакеты.

```go
func TestMain(m *testing.M) {
    os.Exit(run(m)) // run использует defer корректно
}
func run(m *testing.M) (code int) {
    container, pool := mustStart()
    defer func() { pool.Close(); _ = container.Terminate(context.Background()) }()
    testPool = pool
    return m.Run()
}
```

### Изоляция между тестами при общем контейнере
Один контейнер на пакет → тесты делят БД. Варианты изоляции:
1. **Транзакция с откатом:** каждый тест в своей транзакции, `defer tx.Rollback()` — состояние не утекает. Минус: нельзя тестировать код, который сам управляет транзакциями/коммитит.
2. **Отдельная схема/БД на тест:** `CREATE SCHEMA test_<random>` + `search_path`, или отдельная database. Полная изоляция, дороже.
3. **Truncate/cleanup между тестами** через `t.Cleanup`: очищать таблицы. Просто, но требует осторожности с параллельностью.
4. **Уникальные данные:** префиксы/UUID в ключах, чтобы тесты не пересекались (для параллельных).

Для `t.Parallel()` с общей БД нужна реальная изоляция (схема/БД на тест), иначе гонки данных.

### Build tags: разделение unit и integration
```go
//go:build integration

package repo_test
```
Запуск:
```bash
go test ./...                      # только unit (файлы без тега)
go test -tags=integration ./...    # unit + integration
```
Альтернатива — `testing.Short()`:
```go
func TestIntegration(t *testing.T) {
    if testing.Short() {
        t.Skip("skipping integration test in -short mode")
    }
    // ...
}
```
`go test -short ./...` пропустит. Разница: build tag **исключает файл из компиляции** (быстрее, чище разделение, не тянет docker-зависимости в обычную сборку), `-short` компилирует, но пропускает в рантайме. Для тяжёлой инфраструктуры предпочтителен build tag.

### CI
- Отдельный job/stage для интеграционных: нужен Docker(-in-Docker) или доступ к docker-сокету.
- Unit-стадия быстрая, блокирует PR; интеграционная может быть тяжелее.
- testcontainers работает в CI, где есть Docker (GitHub Actions, GitLab с dind). Альтернатива в GitHub Actions — `services:` контейнеры, но testcontainers даёт ту же конфигурацию из кода и переносимость на локальную машину.

## Подводные камни / gotchas
- **Sleep вместо wait strategy** — главный источник флаки. Контейнер стартовал ≠ сервис готов. Используйте `wait.ForSQL`/`ForLog(WithOccurrence)`/`ForHTTP`.
- **Postgres «ready» дважды.** Первый «ready» — во время init-скриптов, затем рестарт. `wait.ForLog("ready to accept connections").WithOccurrence(2)` или `wait.ForSQL`.
- **`os.Exit` в TestMain съедает defer.** Teardown до `os.Exit` или через обёртку с defer + возврат кода.
- **Забыли `m.Run()`** в TestMain — тесты не запустятся, а CI «зелёный».
- **Утечка контейнеров** при kill теста. Ryuk подчищает; при `RYUK_DISABLED` — ваша ответственность.
- **Параллельные тесты на общей БД** без изоляции → гонки данных, флаки. Схема/БД на тест или отказ от parallel.
- **Хардкод порта/хоста.** Всегда `MappedPort`/`Host` — иначе конфликт при параллельных прогонах и в CI.
- **Тяжесть.** Контейнер на каждый тест убивает скорость. Один на пакет (TestMain) + изоляция данными/транзакциями.
- **Зависимость от Docker.** На машине без Docker интеграционные падают — отсюда build tags, чтобы `go test ./...` не требовал Docker.
- **Pull образов** в CI без кэша — медленно и хрупко (rate limits). Кэшируйте/пиньте теги (`postgres:16-alpine`, не `latest`).
- **Версия образа = версии прода.** Тестируйте против той же мажорной версии БД, что в проде, иначе диалект/поведение разойдутся.

## Вопросы на собеседовании

**В:** Зачем интеграционные тесты, если есть моки репозитория?
**О:** Моки не проверяют реальный SQL, миграции, типы колонок, констрейнты, транзакционную изоляцию, поведение драйвера и сериализацию. Интеграционный тест против настоящей БД ловит опечатки в запросах и расхождения с реальным движком, которые мок принципиально не увидит.

**В:** Что даёт testcontainers-go по сравнению с docker-compose для тестов?
**О:** Зависимости описаны в коде теста, поднимаются/гасятся программно с динамическими портами (нет конфликтов и хардкода), корректные wait-стратегии, автоуборка через Ryuk, одинаково работает локально и в CI. Не нужно держать общую тестовую БД и синхронизировать compose-файл.

**В:** Почему нельзя ждать готовности контейнера через `time.Sleep`?
**О:** «Контейнер запущен» не значит «сервис принимает соединения» — время старта варьируется, Sleep либо флаки (мало), либо медленно (с запасом). Нужны wait strategies: `wait.ForSQL`, `wait.ForListeningPort`, `wait.ForLog(...).WithOccurrence(n)`, `wait.ForHTTP`, которые опрашивают реальную готовность.

**В:** Зачем `TestMain` и какие с ним подводные камни?
**О:** Единая точка setup/teardown на пакет — поднять контейнер один раз, а не на каждый тест. Подводные камни: если `TestMain` объявлен, тесты идут только через `m.Run()`; `os.Exit` не вызывает `defer`, поэтому teardown делают до него или через обёртку с defer; один TestMain на пакет.

**В:** Как изолировать тесты при одном контейнере на пакет?
**О:** Транзакция с откатом на тест (быстро, но не для кода, который сам коммитит), отдельная схема/БД на тест (полная изоляция, дороже), truncate/cleanup через `t.Cleanup`, уникальные ключи/префиксы. Для `t.Parallel()` на общей БД нужна реальная изоляция (схема/БД), иначе гонки данных.

**В:** Чем build tag отличается от `testing.Short()` для разделения тестов?
**О:** Build tag (`//go:build integration`) исключает файл из компиляции без тега — обычная сборка не тянет docker-зависимости и быстрее. `-short` компилирует всё, но пропускает помеченные тесты в рантайме. Для тяжёлой инфраструктуры предпочтителен build tag.

**В:** Что такое Ryuk в testcontainers?
**О:** Контейнер-reaper, который testcontainers запускает рядом; он отслеживает и удаляет созданные тестом контейнеры/сети/тома даже при аварийном завершении (kill, паника), предотвращая утечку ресурсов. Отключается `TESTCONTAINERS_RYUK_DISABLED`, тогда уборка на вас.

**В:** Как держать интеграционные тесты быстрыми и стабильными в CI?
**О:** Один контейнер на пакет (TestMain), изоляция данными вместо пересоздания, wait strategies вместо sleep, пиннинг и кэш образов, отдельный CI-stage с Docker, build tags чтобы PR-unit-стадия не зависела от Docker, версия образа = версии прода.

## На что копают на senior+
- **Граница unit/integration:** что мокать, а что проверять реально; почему мок репозитория недостаточен.
- **Изоляция и параллелизм:** транзакции vs схемы vs truncate, корректность при `t.Parallel`, детерминизм.
- **Надёжность:** wait strategies, искоренение sleep и флаки, Ryuk, утечки ресурсов.
- **TestMain-механика:** os.Exit vs defer, один на пакет, разбиение пакетов под разную инфраструктуру.
- **CI-инженерия:** docker-in-docker, кэш/пиннинг образов, разделение стадий, скорость пайплайна, паритет версий с продом.
- **Стратегия тестирования:** пирамида, стоимость/ценность интеграционных, contract tests (один набор против fake и реальной БД).