Что описывает docker-compose файл

Что проверяют

Понимаете ли вы, из чего состоит тестовый стенд и сможете ли поднять его сами, не дёргая разработчиков. Для тестировщика compose это способ получить воспроизводимое окружение, поэтому спрашивают не синтаксис, а что именно в файле описано.

Как отвечать

Compose-файл описывает не приложение, а его окружение целиком: набор сервисов и всё, что нужно для их совместного запуска. Формат YAML, основные разделы:

• services: каждый сервис это будущий контейнер. Внутри image или build, проброс портов, переменные окружения, монтирование каталогов, command, depends_on, healthcheck, ограничения ресурсов;
• volumes: именованные тома для данных, которые должны пережить пересоздание контейнера;
• networks: сети, в которых сервисы видят друг друга по имени сервиса;
• необязательные configs, secrets, profiles, чтобы включать часть стенда только для отдельных прогонов.

Дальше переведите это на язык тестирования: одной командой поднимается связка база, брокер, сервис, заглушки; значения подставляются из .env, поэтому один файл даёт стенд и разработчику, и прогону автотестов; docker compose down -v возвращает чистое состояние между прогонами.

services:
  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s
  api:
    build: .
    depends_on:
      db:
        condition: service_healthy

Где спотыкаются

Думают, что depends_on ждёт готовности зависимости. Без condition: service_healthy он ждёт лишь запуска контейнера, и сервис стартует раньше базы. Мигающие интеграционные тесты чаще всего растут отсюда.

Второе: ищут базу по адресу localhost. Внутри сети compose сервисы обращаются друг к другу по имени сервиса и внутреннему порту, а проброс портов нужен только для доступа с хоста.

Третье: тянут привычки старого формата. Верхнеуровневый ключ version устарел и игнорируется, команда теперь пишется как docker compose. Ещё забывают, что именованные тома переживают остановку стенда, и «чистый» прогон едет на вчерашних данных.