Декораторы в Playwrightт для мобильного тестирования*?***
Нашел классную статью, где автор предлагает избавиться от дублирования кода и упростить поддержкутестов в Playwright. Как? С помощью декораторов TypeScript инкапсулировать платформенно-зависимую логику и создать единый тест для мобильных и настольных платформ.

Читать здесь?

Medium

Mastering Mobile Testing in Playwright: Simplify Your Workflow with TypeScript Decorators

When implementing mobile runs for E2E tests in Playwright, managing the workflow efficiently can be challenging:

?Мокирование конкретных классов вместо интерфейсов
Приложение отправляет уведомления пользователям через SMS.

```
class SmsService {
sendSms(number: string, message: string): void {
// Логика отправки SMS
}
}

class NotificationManager {
constructor(private smsService: SmsService) {}

notifyUser(user: User, message: string): void {
this.smsService.sendSms(user.phoneNumber, message);
}
}
```

Антипаттерн:
В тестах мокируется конкретный класс SmsService.

describe('NotificationManager', () => { it('should send SMS notification', () => { const smsService = new SmsService(); spyOn(smsService, 'sendSms'); const manager = new NotificationManager(smsService); manager.notifyUser({ phoneNumber: '1234567890' }, 'Test Message'); expect(smsService.sendSms).toHaveBeenCalledWith('1234567890', 'Test Message'); }); });

Почему это плохо:
✖️Привязывает тест к конкретной реализации.
✖️Трудно заменить SmsService на другую реализацию (например, для разных стран).
✅Решение:
Использовать интерфейс для абстракции сервиса отправки сообщений.

```
interface IMessageService {
sendMessage(recipient: string, message: string): void;
}

class SmsService implements IMessageService {
sendMessage(recipient: string, message: string): void {
// Логика отправки SMS
}
}

class NotificationManager {
constructor(private messageService: IMessageService) {}

notifyUser(user: User, message: string): void {
this.messageService.sendMessage(user.phoneNumber, message);
}
}

```

?Тестирование с мокированием интерфейса:

describe('NotificationManager', () => { it('should send message notification', () => { const messageService: IMessageService = { sendMessage: jasmine.createSpy('sendMessage'), }; const manager = new NotificationManager(messageService); manager.notifyUser({ phoneNumber: '1234567890' }, 'Test Message'); expect(messageService.sendMessage).toHaveBeenCalledWith('1234567890', 'Test Message'); }); });

?Что-то вроде выводов:
Стремитесь писать тесты, которые проверяют поведение через публичный интерфейс и фокусируются на результатах, а не на деталях реализации. Это сделает ваш код более надежным, а тесты — более ценными инструментами в процессе разработки.

Было полезно? Ставьте *?*?****

Выход playwright 1.47

⚡ Обновления Playwright:

1⃣ Network Tab (небольшие улучшения в UI mode и trace viewer)
⚪ Фильтрация по типу запроса и URL
⚪ Улучшенное отображения query parameters
⚪ Превью для шрифтов

*2⃣ *Опция — tsconfig
Теперь можно указать конкретный tsconfig для всех импортируемых файлов:

npx playwright test \-\-tsconfig tsconfig.test.json

3⃣ APIRequestContext
Поддержка URLSearchParams в query параметрах:

const response = await request.get('url', { params: 'userId=1' });

https://github.com/microsoft/playwright/releases/tag/v1.47.0

?Структура юнит тестов

Меня читают много разработчиков и скорее всего это пост для них.

При написании юнит тестов возникает необходимость структурировать код таким образом, чтобы он был понятным, легко поддерживаемым и эффективно выявлял ошибки. Один из наиболее популярных подходов для достижения этих целей — паттерн AAA (Arrange-Act-Assert).

Патерн делит процесс написание тестов на 3 логические части:
⚪️ Arrange (Подготовка) — вы готовите все необходимые данные и зависимости для теста
⚪️ Act (Действие) — выполняете основное действие, которое хотите протестировать
⚪️ Assert (Проверка) — на заключительном этапе вы проверяете результаты действия.

Пример прям из тестов текущего проекта:

```
test('Закрывает Drawer при вызове onClose', () => {
// Arrange
render();
const closeButton = screen.getByRole('button', { name: 'close' });

// Act
fireEvent.click(closeButton);
TypeScript
// Assert
expect(mockedUseStore().services.comments.close).toHaveBeenCalled();
});
```

Рекомендации?
Почти все эти рекомендации можно соблюдать автоматически настроив правила
eslint-a с плагином eslint-plugin-jest.

✖️ Избегайте тесты где используются несколько секций Arrange, Act, Assert.
Например:

```
test('Закрывает и открывает Drawer при вызове onClose', () => {
// Arrange
render();
const closeButton = screen.getByRole('button', { name: 'close' });

// Assert
expect(modal).toBeVisible();
});
```

✖️ Избегайте if в тестах.
Тесты должны быть последовательны и без ветвлений.
Включите правило линтера: no-conditional-in-test.

✔️ Один тест — одно действие
✔️ Один тест — одно утверждение, это не всегда возможно, старайтесь, чтобы в каждом тесте проверялось одно конкретное поведение. Это упрощает диагностику при возникновении ошибок.
Можно использовать правила линтера:
➡️ expect-expect — правило следит, что во всех тестах есть expect
➡️ max-expects — максимальное число expect в тестах

По мотивам книги Принципы юнит-тестирования?

Как сделать так, чтобы в ветку попадал только чистый и рабочий код?*?‍?***

В разработке важно, чтобы в ветку попадал код, который соответствует стандартам и не ломает приложение или на код-ревью не писали ? Один из эффективных способов это обеспечить — использование Git хуков, особенно pre\-commit. Этот хук запускает проверки до того, как изменения будут зафиксированы, и позволяет автоматизировать запуск линтера и тестов перед каждым коммитом.

Для упрощения этого процесса есть масса различных библиотек?:
?husky (nodejs)
?pre-commit (python)
?использовать нативные (для любого проекта)

Пример настройки для nodejs husky?
Прежде чем приступать к настройки у нас должны быть установлены linter, prettier

Пример package.json

{ "scripts": { "lint": "eslint .", "format": "prettier . \-\-write", "test": "jest" } }

Команда init упрощает настройку husky в проекте. Он создает pre\-commit в .husky/ и обновляет сценарий для подготовки в package.json.

npx husky init

Дальше просто добавляем наши скрипты проверки качества кода

echo "npm prettier && npm lint && npm test" > .husky/pre\-commit

После можно попробовать сделать коммит и наши скрипты запустятся

Если вам надо закоммитить быстро можно отключить запуск хуков

git commit \-m "..." \-n

Было полезно? Ставьте *?*?****

Локаторы vs селекторы??

Что такое селекторы и локаторы в Playwright?

? Селекторы — это строки, которые используются для сопоставления элементов в DOM страницы. Playwright поддерживает различные типы селекторов, включая поиск по тексту, CSS, XPath и другие.

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

Я планирую написать подробное руководство о том, как и какой локатор лучше использовать. Вот выдержка из документации по рекомендуемым локаторам. Если ни одна из функций не подходит, можно добавить атрибут data-testid:
?page.getByRole() для поиска по явным и неявным атрибутам доступности.
?page.getByText() для поиска по текстовому содержимому.
?page.getByLabel() для поиска по лейблу
?page.getByPlaceholder() для поиска поля ввода по плейсхолдеру.
?page.getByAltText() для поиска элемента, по альтернативному тексту.
?page.getByTitle() для поиска элемента по его атрибуту title.
?page.getByTestId() для поиска элемента по атрибуту data-testid.

Было полезно? Ставьте *?*?****

?Захват и анализ сетевого трафика прямо в браузере

Захват и анализ сетевого трафика через chrome://net-export. Это может быть полезно ⬇️
?Если требуется захватить сетевой трафик в течение длительного периода времен
?Когда нужно анализировать трафик, связанный с несколькими сетями или интерфейсами (например, при переключении между Wi-Fi и сотовой сетью)
?Если DevTools не дает всей необходимой информации о сетевых ошибках или задержках, chrome://net\-export/ может предоставить более подробные данные, включая информацию о сетевых пакетах, DNS-запросах и внутренней работе браузера.
?Для отслеживание 2 вкладок.

В Chrome есть встроенная функция net\-export, которая проста и удобна в использовании:
1️⃣ Откройте страницу chrome://net-export.
2️⃣Нажмите «Start Logging to Disk».
3️⃣Укажите расположение и название файла, который будет сохранен в формате JSON.
4️⃣После завершения работы нажмите «Stop Logging to Disk»

В итоге, chrome://net\-export/ чаще используется для более глубокого и продолжительного анализа сетевой активности, когда стандартных возможностей DevTools недостаточно для решения задач.

Дальше открываешь полученный JSON netlog-viewer.appspot.com

Ставьте ??