Как сделать отчёты Playwright понятными, а падения — полезными

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

Some page › some action: param-value

Но это подходит в случае, если тест отчетность нужна на английском.

___

Кстати, ещё можно отметить, что в 1.53.0 версии плейрайта добавили фичу, помогающей присвоить описание локаторов. Можно почитать об этом в релизнотах

Теперь и действия с локаторами по типу click, fill, clear и тд, будут иметь описание по дефолту.

Конечно, locator.desctibe пока что работает не очень хорошо, описание теряется, при вызове элемента по индексу, использованию locator.all(), first(), last() и в общем любой функции возвращающей локатор, но есть способы обойти это ограничение и получить улучшенную тест отчетность без дополнительных step

Быстрый старт автотестирования с Playwright

Спасибо за статью, было интересно почитать.

Page Object может содержать селекторы и методы для работы со страницей.

На мой взгляд, когда одновременно селекторы/локторы и методы для работы со страницей в одном классе, особенно, когда локаторов становится много - получается каша из кучи локаторов и нескольких методов, становиться сложнее ориентироваться. Мне нравится разбивать отдельно на класс с локаторами и класс страницы с методами для работы со страницей и инстансом класса локаторов, так и больше по single-responsibility principle (SRP), и в целом работать с классом в дальнейшем проще.

4. Класс - шаблон, для описания переменных окружения, адаптируемый для каждого проекта индивидуально support\utilities\EnvHelper.ts:

Кстати, ещё можно решить этот вопрос просто задекларировав модуль process:

declare module 'process' {
  global {
    namespace NodeJS {
      interface ProcessEnv {
        NAME_APP: string
        BASE_URL: string
        LOGIN: string
        PASSWORD: string
        TEST_TIMEOUT: string
        ACTION_TIMEOUT: string
        EXPECT_TIMEOUT: string
      }
    }
  }
}

И теперь при вызове process.env. будут перечислены ваши переменные окружения

Но такой подход будет хуже используемого в статье, если:
1. Хочется задать дефолтные значения (в случае, когда переменная окружения не задана)
2. Нужно парсить например string в number

______

Надеюсь, что не слишком душно, но всё же отмечу:

• В докер файле видно, что за основу мы используем образ плейрайта, но при этом мы всё равно устанавливаем плейрайт npx playwright install --with-deps , что по сути не нужно, потому что плейрайт, все браузеры и тд уже предустановлены, нужно только затянуть зависимости вашего проекта.
  Я вижу, что есть if/else, и установка срабатывает тогда, когда нет модуля, но всё таки можно было бы ограничиться и просто npm i

• В support\utilities\EnvHelper.ts мы парсим в том числе все таймауты, а в конфиге используем хардкодные значения