Jest + кукловод лучшие архитектурные практики - PullRequest
Новая
       44

Jest + кукловод лучшие архитектурные практики

5 голосов
/ 28 февраля 2020

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

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

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

Тогда у меня есть тестовый файл для каждой страницы или для каждого компонента. (например, файл landingPage.tests.js, который использует модель класса LandingPage в файле LandingPage.js)

Вот конкретный пример: у меня есть разные случаи входа в систему, и я хотел бы проверить их все , Например, я хочу протестировать соединение с «обычным» пользователем, для которого процесс просто логин, а затем пароль. Затем мне нужно провести тестирование с пользователем, который активировал 2FA, или с пользователем из компании, которая использует SSO.

Сначала я подумал о том, чтобы поместить свои разные тесты в authentication.tests.js, в разные блоки describe, думая, что каждый раз будет открываться новая вкладка, но это не так ... Я использую кукловода в режиме инкогнито, чтобы убедиться, что каждая вкладка является изолированным сеансом.

Итак, мои вопросы:

  • Где лучше всего сделать эти наборы тестов?

  • Должен ли я иметь тестовые файлы, которые "описывают" страницы (например, кнопка должна присутствовать, такой текст должен быть здесь и т. д. c), а также иметь тестовый файл типа сценария (набор контекстных действий для пользователя, например, для разных случаев входа в систему)?

Вот authentication.tests.js, в котором я хотел бы проверить все мои различные способы входа в систему: 

import HeaderComponent from "../../../pages/components/HeaderComponent";
import AuthenticationComponent from "../../../pages/components/AuthenticationComponent";
import LandingPage from "../../../pages/landing/LandingPage";

import {
    JEST_TIMEOUT,
    CREDENTIALS
} from "../../../config";


describe('Component:Authentication', () => {
    let headerComponent;
    let authenticationComponent;
    let landingPage;

    beforeAll(async () => {
        jest.setTimeout(JEST_TIMEOUT);
        headerComponent = new HeaderComponent;
        authenticationComponent = new AuthenticationComponent;
        landingPage = new LandingPage;
    });


    describe('Normal login ', () => {

        it('should click on login and open modal', async () => {
            await landingPage.visit();
            await headerComponent.isVisible();
            await headerComponent.clickOnLogin();
            await authenticationComponent.isVisible();
        });

        it('should type a normal user email adress and validate', async () => {
            await authenticationComponent.typeUsername(CREDENTIALS.normal.username);
            await authenticationComponent.clickNext();
        });

        it('should type the correct password and validate', async () => {
            await authenticationComponent.typePassword(CREDENTIALS.normal.password);
            await authenticationComponent.clickNext();
        });

        it('should be logged in', async () => {
            await waitForText(page, 'body', 'Success !');
        });

    });

    describe('SSO login ', () => {
        // todo ...
    });


});

Спасибо и извините, если это звучит странно, как я сказал, что я пытаясь выяснить, как все это сочетается.

1 Ответ

2 голосов
/ 04 марта 2020

Что касается структуры папок, Jest найдет любые файлы в соответствии с match config , в основном все, что называется * .spe c. js или * .test. js. Похоже, ты это уже знаешь.

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

Другое преимущество всех тестов в одной папке состоит в том, что вы можете начать различать guish между типами испытаний. Тесты компонентов проверяют, что чистые компоненты отображаются и работают как ожидалось. Для этого вам не нужен Puppeteer, используйте снимки, если вы находитесь в приложении React. Puppeteer хорош для интеграционных тестов, которые перемещаются по так называемым «счастливым путям», входят в систему, регистрируются, добавляются в корзину и т. Д. c., Используя браузер Chromium без головы.

Чтобы ответить на конкретную проблему c, которую вы испытывали с Jest / Puppeteer, на новой странице для каждого теста: 

//keep a reference to the browser 
let browser
//keep a reference to the page
let page

// open puppeteer before all tests
beforeAll(async () => {
  browser = await puppeteer.launch()
})

// close puppeteer after all tests
afterAll(async () => {
  await browser.close()
})

// Get a new page for each test so that we start fresh.
beforeEach(async () => {
  page = await browser.newPage()
})

// Remember to close pages after each test.
afterEach(async () => {
  await page.close()
})

describe('Counter', () => {
  // "it" blocks go here.
})

Надеюсь, что это немного поможет.

...