Что пишут в блогах

Подписаться

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

.
Создание плагина конфигурации в Cypress
04.08.2022 00:00

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разбирался с конфигурацией Cypress. Я обнаружил, что особенно трудно настраивать разные окружения, особенно для новичков. В этой статье я разобью конфигурацию на последовательность небольших шагов, и это поможет вам ориентироваться в теме.

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

У любого проекта Cypress есть файл cypress.json. В этом файле есть атрибут env, который обычно заполняется переменными окружения. Допустим, я добавил в этот атрибут переменную app:

cypress.json
{
"env": {
"app": "local"
}
}

Если открыть Cypress в GUI-режиме, то во вкладке настроек я увижу, что мой конфигурационный файл прочитан и подсвечен голубым.


Как можно видеть на скриншоте, существует несколько способов добавлять переменные окружений. Их можно выделить в файл cypress.env.json, добавить их с префиксом CYPRESS_ в свое окружение или передавать через CLI, как аргументы. Взгляните на документацию – там есть примеры для всех этих подходов.

Создание плагина

При более сложной настройке эти подходы имеет смысл комбинировать. Допустим, у вас несколько окружений – local, staging, preprod, prod. У каждого из них есть свой домашний URL, своя версия API, своя страница перенаправления. Такие конфигурации могут выглядеть как-то так:

// local
baseUrl: 'http://localhost:3000'
api: 'development'
redirect: 'https://www.product-staging.com'
 
// staging
baseUrl: 'http://dashboard.product-staging.com'
api: 'development'
redirect: 'https://www.product-staging.com'
 
// preprod
baseUrl: 'http://dashboard-preprod.product.com'
api: 'v2'
redirect: 'https://www.product.com'
 
// prod
baseUrl: 'http://dashboard.product.com'
api: 'v1'
redirect: 'https://www.product.com'

Как можно видеть, это немного бестолково, но часто случается в реальной жизни. У вас разные комбинации API и URL, отличающиеся для разных окружений. Более того, вам могут понадобиться ключи или секретные данные, которых не должно быть в базе кода. Разберемся, как это сделать.

Для начала посмотрим, как работает конфигурация. Когда вы добавите этот код в файл cypress/plugins/index.ts, то увидите логирование переменных вашего окружения. Если бы у меня все еще был мой старый cypress.json, то я бы увидел в терминале { app: 'local' }, открыв Cypress через npx cypress open.

cypress/plugins/index.js
module.exports = (on, config) => {
console.log(config.env) // { app: 'local' }
}

Очистим наш cypress.json и вместо этого передадим флаг версии в окружение через CLI, примерно так:

npx cypress open --env version="prod"

Открыв Cypress, вы увидите лог { version: 'prod' } в терминале. Теперь воспользуемся этой информацией и изменим конфигурационный файл согласно тому, что мы передаем во флаге version.

cypress/plugins/index.js
module.exports = (on, config) => {
if (config.env.version === "prod") {
config.baseUrl = 'http://dashboard.product.com'
config.env.api = 'v2'
config.env.redirect = 'https://www.product.com'
    }
return config
}

Теперь, используя наш плагин, мы добавляем другие переменные в нашу env. Если посмотреть на настройки в Cypress SLI, то мы увидим, что переменные добавлены.


Это помогает продемонстрировать, как работает плагин конфигурации. Предположим теперь, что пути нашей конфигурации хранятся в отдельных json-файлах, для которых мы создали специальную папку "config" в нашем проекте Cypress:

cypress/
├── config/
│   ├── local.json
│   ├── staging.json
│   ├── preprod.json
│   └── prod.json

Теперь допустим, что для каждого флага version необходимо загружать разные файлы и передавать их в Cypress как конфигурацию и окружение. Чтобы это сделать, можно переписать файл плагина так:

cypress/plugins/index.js
module.exports = (on, config) => {
// если версия не задана, использовать local
const version = config.env.version || 'local'
// загрузка env из json
config.env = require(`../config/${version}.json`);
// изменение baseUrl
config.baseUrl = config.env.baseUrl
return config
}

В этом случае мы можем загружать какой угодно файл, и даже добавить дополнительные json-файлы для разных конфигураций. Прочитан будет любой переданный в CLI файл. Теперь подвинемся еще дальше и вместо использования флага CLI задействуем переменную окружения Cypress:

cypress_version=preprod npx cypress open

Как уже упоминалось, все, что передано в CLI с префиксом cypress_ будет добавлено в качестве переменной окружения. Обратите внимание, как я передаю их до того, как ввожу npx cypress open – в отличие от флага –env, который передается после.

Хранение секретов

Возможно, у вас есть ключи и иная секретная информация, которую нежелательно хранить в базе кода. Обычно вы держите это в файлах .bashrc или .zshrc, в зависимости от используемой оболочки. Или же вы пользуетесь плагином dotenv для хранения переменных проекта. Это тоже рабочий вариант. Чтобы прочитать эти переменные и задействовать их в тестах, добавим следующий код в конфигурацию:

There are probably couple of keys or secrets that you don’t want to keep in your code base. You usually keep them in your .bashrc or .zshrc file, depending on what shell you use. Or you may use dotenv plugin to store your variables per project. This works too. To read these variables and use them in your tests, you can add following to your configuration:

cypress/plugins/index.js
module.exports = (on, config) => {
// если версия не задана, использовать local
const version = config.env.version || 'local'
// загрузка env из json
config.env = require(`../config/${version}.json`);
// изменение baseUrl
config.baseUrl = config.env.baseUrl
// добавление секретного ключа
config.env.SECRET_KEY = process.env.SECRET_KEY
return config
}

Теперь, когда вы откроете ваши тесты, в настройках проекта отобразится SECRET_KEY.


Обсудить в форуме