Масса проверяемых веб-продуктов требует определенного уровня аутентификации. Тестируя подобное ПО, QA должны иметь возможность оперировать определенным тестовым пользователем. Традиционно, он генерируется случайным образом и потом используется в большинстве проверок. Далее в статье речь пойдет о наиболее востребованных типах генерации пользователей при использовании Cypress-тестов.
Материал содержит более технический контент, а значит будет понятен только тем читателям, которые имеют определенные навыки работы с данном продуктом, например выполняющих ecommerce тестирование.
cypress.io
Работа с методами
Итак, мы берем файл support/index.js и добавляем тестовый метод before() либо же beforeEach().
Как результат, получим:
const { internet } = require(‘faker’);
const email = internet.exampleEmail()
const password = internet.password()
beforeEach(() => {
cy
.request(‘POST’, ‘/signup’, { email, password })
.then(({ body }) => {
cy
.setCookie(‘trello_token’, body.accessToken);
});
});
Вспомогательный инструмент Faker позволит генерировать различные примеры тестовых почтовых адресов для каждого пользовательского теста.
Процесс авторизации перед каждой проверкой может создавать массу тестовых данных. С одной стороны, подобная операция позволяет тестам быть независимыми друг от друга. И это хорошо! Но работа по созданию нового пользователя для каждой проверки – очень кропотливая и долгая.
Создание тестового скрипта
Обычно, перед началом проверки через Cypress run можно запускать скрипты, которые автоматически создают пользователя с последующим сохранением его в определенный файл. Далее этот файл используется QA-специалистами в тесте для основ авторизации виртуального пользователя.
Содержание тестового signup.js
const axios = require(‘axios’)
const { internet } = require(‘faker’);
const email = internet.exampleEmail()
const password = internet.password()
const fs = require(‘fs’)
const signupUser = async () => {
const user = await axios
.post(‘http://localhost:3000/signup’, { email, password })
fs.writeFileSync(«./cypress/data.json», JSON.stringify(user.data))
}
signupUser()
Его можно запускать как отдельный тестовый сценарий, который задается в файле package.json.
package.json
«scripts»: {
«start»: «cd trelloapp && npm start»,
«cy:run»: «cypress run»,
«createUser»: «node signupUser.js»
}
Обладая данным сценарием, его можно запускать через npm run createUser, а затем прогонять проверки: npm run cy:run.
cypress/plugins/index.js
const signupUser = require(‘../../signupUser.js’)
module.exports = async (on, config) => {
config.env = await signupUser()
return config;
}
Cypress придется ждать, пока не выполнится функция signupUser(), а потом сохранить информацию, которая будет возвращена параметром внутрь объекта config. В таком случае информация генерируется в процессе прогона теста и будет доступна только тогда, когда программа Cypress запущена. Если пользователь запускает тесты в параллельной форме (к примеру, на 15 локальных машинах) – данный сценарий будет вызван 15 раз. Но это даже к лучшему, ведь в таком случае пользователи не будут мешать друг другу.
Оставить комментарий