Разделение concerns

В тестировании с использованием Puppeteer важно обеспечить чёткое разделение различных аспектов кода, чтобы упростить поддержку и расширяемость тестов. Это концепция разделения concerns (разделение ответственности) позволяет организовать тесты так, чтобы каждый компонент или класс отвечал за конкретную задачу. В контексте автоматизации веб-приложений с Puppeteer это означает правильное распределение логики между различными слоями теста, от взаимодействия с браузером до обработки тестовых данных и ассертов.

Модульность тестов

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

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

Пример: 

class LoginPage {
  constructor(page) {
    this.page = page;
    this.usernameInput = page.$(&
    this.passwordInput = page.$('#password');
    this.loginButton = page.$('#login');
  }

  async login(username, password) {
    await this.usernameInput.type(username);
    await this.passwordInput.type(password);
    await this.loginButton.click();
  }
}

В этом примере класс LoginPage инкапсулирует всю логику, связанную с авторизацией, и предоставляет интерфейс для взаимодействия с элементами на странице. Это упрощает повторное использование и тестирование, так как код для авторизации теперь централизован.

Сложные асинхронные операции

Поскольку взаимодействие с браузером через Puppeteer асинхронно, важно правильно структурировать код, чтобы избежать дублирования логики или ошибок синхронизации. Разделение concerns позволяет чётко разграничить те операции, которые должны выполняться последовательно, и те, которые можно параллелить.

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

Пример: 

class TestHelper {
  static async prepareTestData(page) {
    // Заполнение формы или подготовка тестовых данных
  }

  static async cleanup(page) {
    // Очистка cookies, локального хранилища и т.д.
  }
}

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

Использование паттернов проектирования

Для дальнейшего улучшения разделения concerns в тестах с Puppeteer можно использовать паттерны проектирования. Один из таких паттернов — Page Object Pattern (паттерн объектов страниц). Этот паттерн предполагает создание объектов для каждой страницы или компонента, как было показано в примере с классом LoginPage. Однако для сложных интерфейсов, например, с несколькими модулями или динамически изменяющимися элементами, можно внедрить более сложные паттерны, такие как:

  • Factory Pattern — для создания сложных объектов в зависимости от условий теста.
  • Singleton Pattern — для обеспечения того, чтобы экземпляр страницы или компонента создавался только один раз.

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

Логирование и обработка ошибок

Логирование и обработка ошибок — это ещё один аспект, который должен быть отделён от основной логики теста. Для этого можно использовать отдельные классы или модули, отвечающие за сбор информации о тестах, таких как результат выполнения, ошибки или метки времени.

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

Пример: 

class Logger {
  static log(message) {
    console.log(`[Test Log] ${message}`);
  }

  static error(message) {
    console.error(`[Test Error] ${message}`);
  }
}

В коде тестов можно использовать эти методы для регистрации информации: 

try {
  await loginPage.login('testuser', 'password');
} catch (error) {
  Logger.error('Login failed');
}

Такой подход делает тесты более прозрачными, а логи легко читаемыми и централизованными.

Тестовые данные

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

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

Пример: 

class TestDataGenerator {
  static generateRandomEmail() {
    return `${Math.random().toString(36).substr(2, 9)}@example.com`;
  }

  static generateRandomPassword() {
    return Math.random().toString(36).substr(2, 8);
  }
}

Теперь тесты могут использовать эти методы для генерации данных: 

const email = TestDataGenerator.generateRandomEmail();
const password = TestDataGenerator.generateRandomPassword();
await loginPage.login(email, password);

Удобство в масштабировании

Когда проект растёт, тесты становятся более сложными. Разделение concerns позволяет тестировщикам и разработчикам легко масштабировать тесты, добавлять новые сценарии и функциональности без разрушения существующей логики. Модульный подход способствует лучшему распределению нагрузки, в случае ошибок можно точно локализовать проблему в одном из слоёв.

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

Заключение

Разделение concerns в тестировании с Puppeteer — это не просто хорошая практика, а необходимое условие для написания эффективных, масштабируемых и поддерживаемых тестов. С использованием правильных паттернов проектирования и модульного подхода можно минимизировать зависимость между различными аспектами тестов и сделать код более гибким и удобным для изменения.

Оглавление