Что хранится в Conf.test?

Структура и содержимое конфигурационного файла conf.test

В конфигурационных файлах для тестирования, часто именуемых как conf.test, config.test, test.properties или подобными, хранится набор параметров и настроек, необходимых для корректного выполнения автоматизированных тестов. Эти файлы отделяют конфигурацию от кода, повышая гибкость, безопасность и поддерживаемость тестовой инфраструктуры. Ниже подробно разберём типовое содержимое такого файла.

Типичные секции и параметры

1. Среда выполнения и адреса сервисов

Это фундаментальная часть, определяющая, где и как запускаются тесты.

# Пример в формате YAML
environment: "staging"
base_url: "https://api.staging.example.com"
ui_url: "https://staging.example.com"
auth_service_url: "https://auth.staging.example.com"

Или в формате JSON/Properties:

# Пример в формате properties
environment=staging
base.url=https://api.staging.example.com
ui.url=https://staging.example.com

• environment: Определяет целевое окружение (staging, production, local, qa). Это позволяет одним набором тестов работать с разными инстансами приложения.
• base_url: Корневой URL API, к которому будут отправляться запросы.
• ui_url: Основной адрес веб-интерфейса для UI-тестов.

2. Параметры аутентификации и авторизации

Ключи, токены и учётные данные для доступа к системе. ВАЖНО: реальные пароли здесь не хранятся, только их идентификаторы или пути к секретным файлам.

api.key=${API_KEY_FROM_ENV}
test.user.username=test_automation
test.user.password.ref=/secrets/test_user.pwd
auth.token.endpoint=/oauth/token

Часто используется связь с переменными окружения (${API_KEY_FROM_ENV}) или внешними системами управления секретами для безопасности.

3. Настройки драйверов и браузеров

Для Selenium или других инструментов UI-тестирования.

// Пример в JSON
{
  "browser": "chrome",
  "browser_version": "latest",
  "headless_mode": true,
  "implicit_wait_seconds": 10,
  "page_load_timeout_seconds": 30
}

• headless_mode: Позволяет запускать браузер без графического интерфейса для скорости и CI/CD.
• timeouts: Критичные параметры для стабильности тестов, управляющие ожиданиями.

4. Параметры базы данных и внешних сервисов

Для интеграционных тестов, проверяющих взаимодействие с БД, почтой, файловыми хранилищами.

database:
  test_jdbc_url: "jdbc:postgresql://test-db-host:5432/test_db"
  test_db_user: "test_user"
  test_db_schema: "test_schema"
external_service:
  mock_server_url: "http://localhost:8083"
  email_gateway: "https://mailhog.staging.example.com"

5. Флаги и режимы выполнения тестов

Управляют поведением тестового фреймворка.

test.run.parallel=true
test.retry.count=2
test.log.level=DEBUG
enable.video.recording=false
report.generate.allure=true

• test.run.parallel: Включает параллельный запуск для экономии времени.
• test.retry.count: Число повторений упавших тестов для борьбы с нестабильностью.
• report.generate.allure: Указывает на генерацию детализированного отчёта в формате Allure.

6. Пути к файлам и ресурсам

Логическая организация тестовых данных и артефактов.

test.data.dir=/resources/test_data/
test.screenshot.dir=/artifacts/screenshots/
download.path=/tmp/test_downloads/
fixture.path=src/test/fixtures/

Форматы файлов и способы чтения

Файл conf.test может быть составлен в различных форматах, выбор которого зависит от фреймворка и предпочтений команды:

• .properties (Java-ориентированный, простой ключ-значение)
• .yaml / .yml (более структурированный, популярен в Python и современных фреймворках)
• .json (стандартный для многих языков)
• .ini (секционированный, но менее мощный)
• .env (очень простой, часто для базовых переменных)

Чтение конфигурации в коде тестов обычно абстрагировано в специальный класс или модуль. Например, в Python с использованием pytest и библиотеки pyyaml:

# config_reader.py
import yaml
import os

class TestConfig:
    def __init__(self, config_path='conf.test.yml'):
        with open(config_path, 'r') as file:
            self._config = yaml.safe_load(file)
        # Можно также подгрузить переменные окружения
        self.base_url = os.getenv('BASE_URL', self._config['base_url'])

    def get_browser(self):
        return self._config.get('browser', 'chrome')

# Использование в тесте
config = TestConfig()
driver = webdriver.Chrome() if config.get_browser() == 'chrome' else webdriver.Firefox()
api_client = ApiClient(base_url=config.base_url)

Принципы хорошей конфигурации для тестов

1. Отделение от кода: Конфигурация должна быть внешней. Это позволяет изменять окружение без переписывания тестов.
2. Секционирование: Параметры должны быть логически сгруппированы (env, db, browser, flags).
3. Безопасность: Никаких реальных паролей или токенов в plain text. Используйте переменные окружения или системы управления секретами (Hashicorp Vault, AWS Secrets Manager).
4. Документирование: Файл должен быть понятен. Комментарии в форматах .properties или .yaml помогают новым членам команды.
5. Поддержка нескольких окружений: Часто используется шаблон conf.{environment}.test (например, conf.staging.test, conf.local.test) или единый файл с переопределением через переменные.

Таким образом, conf.test служит центральным хранилищем управляющих параметров тестовой системы. Он обеспечивает портабельность тестов между различными средами (CI/CD, локальной машиной разработчика, staging), управление их поведением (параллельность, логирование, повторение) и безопасное предоставление необходимых ресурсов (URL, учётные данные, пути к данным). Правильно организованная конфигурация — это ключ к созданию стабильной, гибкой и легко поддерживаемой автоматизированной тестовой инфраструктуры.