Множественные конфигурационные файлы

Cypress предоставляет гибкую систему конфигурации, позволяя управлять настройками тестирования на разных уровнях. В больших проектах часто требуется использовать разные конфигурационные файлы для различных окружений: development, staging, production, а также для локального запуска и CI/CD. Это позволяет поддерживать чистоту и повторяемость тестов без изменения основного кода тестов.

Основы конфигурации Cypress

Cypress хранит конфигурацию в файле cypress.config.js (или cypress.config.ts при использовании TypeScript). Стандартная структура файла включает объект с ключами:

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    specPattern: 'cypress/e2e/**/*.cy.js',
    supportFile: 'cypress/support/e2e.js'
  },
  viewportWidth: 1280,
  viewportHeight: 720,
  defaultCommandTimeout: 5000
});

Ключевые моменты конфигурации:

  • baseUrl — базовый URL для всех тестов.
  • specPattern — шаблон поиска файлов тестов.
  • supportFile — путь к файлу поддержки, содержащему общие команды и хуки.
  • defaultCommandTimeout — время ожидания команд Cypress.

Эти значения могут меняться для разных окружений, что делает необходимым использование множественных конфигурационных файлов.

Поддержка нескольких конфигураций

Cypress позволяет создавать отдельные конфигурационные файлы и загружать их при запуске тестов через CLI. Стандартный подход: хранить конфиги в папке cypress/config/ с именами, отражающими окружение, например:

cypress/config/
 ├─ dev.config.js
 ├─ staging.config.js
 ├─ prod.config.js

Пример staging.config.js:

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'https://staging.example.com',
    specPattern: 'cypress/e2e/**/*.cy.js',
    supportFile: 'cypress/support/e2e.js'
  },
  viewportWidth: 1440,
  viewportHeight: 900,
  defaultCommandTimeout: 10000
});

Запуск Cypress с указанием конфигурации

Использование CLI позволяет запускать тесты с конкретным конфигом через флаг --config-file:

npx cypress run --config-file cypress/config/staging.config.js

Это автоматически переопределяет стандартные настройки из основного cypress.config.js. Таким образом, можно поддерживать отдельные параметры для локальной разработки, CI и продакшн-тестирования.

Использование переменных окружения

Для повышения гибкости вместе с множественными конфигурациями часто применяются переменные окружения. Они задаются в конфигурации или через CLI:

module.exports = defineConfig({
  e2e: {
    baseUrl: process.env.BASE_URL || 'http://localhost:3000',
  },
  env: {
    apiToken: process.env.API_TOKEN,
    featureFlag: true
  }
});

Запуск с переменной окружения:

BASE_URL=https://staging.example.com API_TOKEN=12345 npx cypress run --config-file cypress/config/staging.config.js

Cypress предоставляет доступ к переменным окружения через Cypress.env():

cy.request({
  method: 'GET',
  url: '/api/data',
  headers: {
    Authorization: `Bearer ${Cypress.env('apiToken')}`
  }
});

Расширение конфигураций через merge

Для упрощения поддержки нескольких конфигов часто используют подход наследования и объединения конфигураций. Например, есть общий базовый конфиг base.config.js, который наследуют все специфичные окружения:

const { defineConfig } = require('cypress');
const merge = require('deepmerge');
const baseConfig = require('./base.config');

module.exports = defineConfig(
  merge(baseConfig, {
    e2e: {
      baseUrl: 'https://dev.example.com',
    },
    defaultCommandTimeout: 8000
  })
);

Такой подход исключает дублирование и облегчает поддержку настроек.

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

Cypress поддерживает разделение конфигурации для e2e и component тестирования:

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    specPattern: 'cypress/e2e/**/*.cy.js'
  },
  component: {
    devServer: {
      framework: 'react',
      bundler: 'vite'
    },
    specPattern: 'cypress/component/**/*.cy.js'
  }
});

Можно иметь отдельные конфигурации для e2e и component тестов в зависимости от окружения, что особенно важно при интеграционном тестировании UI-компонентов.

Советы по организации файлов

  • Все конфигурационные файлы должны быть в одном месте и иметь понятные имена.
  • Для CI/CD можно добавить скрипты в package.json:
"scripts": {
  "test:dev": "cypress run --config-file cypress/config/dev.config.js",
  "test:staging": "cypress run --config-file cypress/config/staging.config.js",
  "test:prod": "cypress run --config-file cypress/config/prod.config.js"
}
  • Использовать переменные окружения для чувствительных данных, чтобы не хранить их в репозитории.
  • Стараться минимизировать различия между конфигами, изменяя только необходимые параметры (baseUrl, viewport, defaultCommandTimeout).

Итоговая структура проекта с множественными конфигами

cypress/
 ├─ e2e/
 │   └─ *.cy.js
 ├─ component/
 │   └─ *.cy.js
 ├─ support/
 │   ├─ e2e.js
 │   └─ commands.js
 ├─ config/
 │   ├─ base.config.js
 │   ├─ dev.config.js
 │   ├─ staging.config.js
 │   └─ prod.config.js
 cypress.config.js
 package.json

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

Оглавление