Локаторы vs селекторы🤓💪

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

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

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

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

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

Теги: #playwright

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

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

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

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

Пример package.json

{ 
  "noscripts": { 
    "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

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

Теги: #husky #lint #prettier #git #commit

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

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

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

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

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

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

    // Act
    fireEvent.click(closeButton);

    // Assert
    expect(mockedUseStore().services.comments.close).toHaveBeenCalled();
  
    // Arrange
    const openCommentButton = screen.getByRole('button', { name: 'Комментарии' });
  
    // Act
    fireEvent.click(openCommentButton);
  
  // Assert
  expect(modal).toBeVisible();
  });

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

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

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

Теги: #unitTests #cleanСode #testing #TDD

Выход 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

Теги: #playwright #updates

💻Антипаттерны юнит тестов

Продолжаем тему с юнит тестами, и поговорим какие существуют антипаттерны при написании юнит тестов.

🔎Тестирование приватных методов
У вас есть класс PaymentProcessor, который обрабатывает платежи и содержит приватный метод для валидации транзакций.

class PaymentProcessor {
  private validateTransaction(transaction: Transaction): boolean {
    // сложная логика
    return transaction.amount > 0 && transaction.currency === 'USD';
  }

  processPayment(transaction: Transaction): string {
    if (this.validateTransaction(transaction)) {
      return 'Payment processed';
    } else {
      return 'Invalid transaction';
    }
  }
}

Антипаттерн:
Делаем метод публичным и тестирование метода validateTransaction напрямую.
Почему это плохо:
✖Нарушает принцип инкапсуляции.
✖Тесты становятся хрупкими при изменении внутренней реализации.
✅Решение:
Тестировать публичный метод processPayment, который использует приватный метод.
Или провести рефакторинг и вынести validateTransaction в отдельный класс.


🔎Раскрытие приватного состояния объекта
Класс Inventory управляет списком товаров на складе.

class Inventory {
  private items: Item[] = [];

  addItem(item: Item): void {
    this.items.push(item);
  }
  getItems(): ReadonlyArray<Item> {
    return this.items;
  }

  // Другие методы...
}

Антипаттерн:
Чтобы упростить тестирование, приватное свойство items делается публичным.
✅Решение:
Тестировать публичный метод processPayment, который использует приватный метод.


🔎Утечка доменных знаний в тесты
Система рассчитывает налог в зависимости от категории продукта.

class TaxCalculator {
  calculateTax(product: Product): number {
    if (product.category === 'Food') {
      return product.price * 0.05;
    } else if (product.category === 'Electronics') {
      return product.price * 0.2;
    }
    return product.price * 0.1;
  }
}

Антипаттерн:
Тест дублирует бизнес-логику при расчете ожидаемого результата.

describe('TaxCalculator', () => {
  it('should calculate tax for food category', () => {
    const calculator = new TaxCalculator();
    const product = { price: 100, category: 'Food' };
    // тут дублируется логика
    const expectedTax = product.price * 0.05;
    const tax = calculator.calculateTax(product);
    expect(tax).toBe(expectedTax);
  });
});

Почему это плохо:
✖Тест повторяет логику, которую должен проверять.
✖При изменении логики необходимо менять и код теста.
✅Решение:
Использовать конкретные значения для ожидаемых результатов.

describe('TaxCalculator', () => {
  it('should calculate 5% tax for food category', () => {
    const calculator = new TaxCalculator();
    const product = { price: 100, category: 'Food' };
    const tax = calculator.calculateTax(product);
    expect(tax).toBe(5);
  });

  it('should calculate 20% tax for electronics category', () => {
    const calculator = new TaxCalculator();
    const product = { price: 200, category: 'Electronics' };
    const tax = calculator.calculateTax(product);
    expect(tax).toBe(40);
  });
});

Теги: #unitTests #cleanСode #TDD #BDD #learning #recommendation #practices

🔎Мокирование конкретных классов вместо интерфейсов
Приложение отправляет уведомления пользователям через 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');
  });
});

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

Теги: #cleanСode #unitTests #TDD #BDD

Декораторы в Playwrightт для мобильного тестирования📲

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

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

Теги: #playwright #cleanСode

Тестирование с параметром noWaitAfter в Playwright🕐

Параметр noWaitAfter в Playwright позволяет настроить, как обрабатываются действия, такие как клики по ссылкам, отправка форм или запуск сетевых запросов. Он определяет, должен ли Playwright ждать завершения вызванного события (навигации или перехода на другую страницу) перед тем, как перейти к следующему шагу.
➡️ noWaitAfter: false (по умолчанию): Playwright ждёт завершения действия перед переходом к следующему шагу.
➡️ noWaitAfter: true: Playwright немедленно переходит к следующему шагу, даже если действие ещё не завершено.

Сценарии использования:
💙 noWaitAfter: true в обработчиках локаторов
С версии Playwright 1.44 параметр noWaitAfter: true можно использовать с обработчиками локаторов. Это особенно полезно при работе с оверлеями или другими элементами, которые могут мешать выполнению действий.

test('Закрытие оверлея с noWaitAfter: true', async ({ page }) => {
    await page.goto('http://localhost:3000');
    
    // Локатор для оверлея
    const overlayLocator = page.locator('#overlay');
    
    // Добавляем обработчик локатора для закрытия оверлея
    await page.addLocatorHandler(overlayLocator, async overlay => {
        await overlay.locator('#closeButton').click(); // Закрытие оверлея
    }, { times: 3, noWaitAfter: true }); // Макс. 3 раза, без ожидания после клика
    
    // Взаимодействие с кнопкой после закрытия оверлея
    await page.click('#fetchWeatherButton');
    
    // Проверка отображения прогноза погоды
    await page.waitForSelector('#weatherDisplay:has-text("Прогноз погоды для Chennai")');
});

В этом примере обработчик кликает на кнопку закрытия оверлея, и благодаря noWaitAfter: true, тест продолжает выполнение, не дожидаясь исчезновения оверлея.

💙 noWaitAfter: false для получения данных
Когда требуется подождать завершения сетевого запроса, например, получения прогноза погоды, параметр noWaitAfter: false гарантирует, что Playwright дождётся завершения запроса.

test('Получение данных погоды с noWaitAfter: false', async ({ page }) => {
  await page.goto('http://localhost:3000');
  
  // Клик по кнопке "Получить прогноз погоды" и ожидание завершения запроса
  await page.click('#fetchWeatherButton', { noWaitAfter: false });
  
  // Проверка отображения данных после загрузки
  await page.waitForSelector('#weatherDisplay:has-text("Прогноз погоды для Chennai")');
  const weatherText = await page.textContent('#weatherDisplay');
  console.log(weatherText);
});

Здесь Playwright ждёт, пока данные полностью загрузятся, чтобы тест был надёжным.

💙 noWaitAfter: true для UI-манипуляций
Для операций, таких как переключение видимости элементов или обновление интерфейса, нет необходимости ждать завершения действий. Параметр noWaitAfter: true позволяет пропускать лишние ожидания.

test('UI-манипуляции с noWaitAfter: true', async ({ page }) => {
  await page.goto('http://localhost:3000');
  
  // Клик по кнопке без ожидания
  await page.click('#toggleButton', { noWaitAfter: true });
  await page.waitForSelector('#toggleElement.visible');
  
  // Симуляция быстрых кликов без ожидания
  await page.click('.rapidButton', { noWaitAfter: true });
  
  // Кастомное действие, активируемое таймером
  await page.click('#customActionButton', { noWaitAfter: true });
  await page.waitForSelector('#customActionResult:has-text("Действие завершено!")');
});

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

❓ Зачем использовать noWaitAfter?
➡️ Ускорение тестов. Пропуская ненужные ожидания, можно значительно повысить скорость выполнения тестов.
➡️ Обеспечение точности. Использование noWaitAfter: false гарантирует, что Playwright будет ждать завершения действий, требующих сетевых запросов или навигации, что снижает риск ложноположительных результатов.

⏰ Когда использовать noWaitAfter?
➡️ Используйте noWaitAfter: false для действий, связанных с навигацией или загрузкой данных.
➡️ Используйте noWaitAfter: true для манипуляций с интерфейсом и других действий, не требующих ожидания.

Теги: #playwright

😉Заключение:
Правильное использование noWaitAfter помогает создавать быстрые и надёжные тесты, оптимизируя время ожидания в зависимости от типа действия.

Источник

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

Теги: #playwright #tools #testing

Архитектура playwright🏠

Когда ты работаешь с инструментом важно исследовать его внутренности и понимать как он работает
Давайте разберем playwright

Корневая директория📝
В корневой директории мы находим следующие папки:
🌸playwright/
🌸browser_patches/
🌸docs/
🌸examples/
🌸packages/
🌸tests/
🌸utils/

А также файл package.json, который включает следующие ключи:

{
  "name": "playwright-internal",
  "private": true,
  "workspaces": ["packages/*"]
}

Файл package.json намекает, что основная функциональность находится внутри директории packages/, поскольку корневой файл помечен как private, имеет в названии "internal" и использует ключ "workspaces", который сообщает Node.js, что проект имеет несколько пакетов. Давайте быстро рассмотрим другие директории верхнего уровня перед тем, как углубиться в папку packages/👇

✳️browser_patches — эта папка содержит патчи для браузеров, добавляющие дополнительные элементы управления и функции к некоторым движкам браузеров, используемых в этом проекте. Интересно, что здесь есть патч для WebKit, позволяющий ему работать на Windows.
✳️ docs — папка docs содержит файлы Markdown, которые компилируются в документацию, представленную на сайте Playwright.
✳️ examples — здесь находятся примеры тестовых скриптов, к которым можно обратиться при начале работы с проектом Playwright.
✳️ tests — даже библиотеки для тестирования должны иметь автоматизированные тесты, которые написаны с использованием Playwright.
✳️ utils — директория utils содержит различные инструменты, используемые во время сборки, Docker-образы, функциональность для Azure, генератор файлов типов и многое другое.

Директория packages✏️
Директория packages содержит более 20 отдельных пакетов, что усложняет понимание. Мы разделим этот список на понятные категории.

Пакеты для отчётности и генерации тестов
Playwright содержит множество различных пакетов для отчётности о тестах, каждый со своим набором функций. Кратко, список пакетов в этой категории:
✳️html-reporter/
✳️recorder/
✳️trace-viewer/
✳️trace/
✳️web/

Эти пакеты содержат код, связанный с обработкой отчётов о тестах или их генерацией с помощью пакета recorder. Кроме того, есть trace и trace-viewer, которые могут записываться во время выполнения тестов Playwright. Пакет web/ предоставляет утилиты, общие для различных веб-инструментов, перечисленных здесь.

Пакеты, специализированные для браузеров
Каждый из этих пакетов просто экспортирует пакет playwright-core вместе со скриптом установки только для соответствующего браузера. Вы можете найти их на npmjs, например, playwright-chromium — это отдельный пакет, который имеет Playwright, специализированный только для автоматизации Chromium.
✳️ playwright-chromium/
✳️ playwright-firefox/
✳️ playwright-webkit/

Пакеты для установки браузеров
Эти пакеты включают только скрипты установки для каждого из браузеров. Например, playwright-browser-chromium соответствует пакету @playwright/browser-chromium на npmjs.
✳️playwright-browser-chromium/
✳️playwright-browser-firefox/
✳️playwright-browser-webkit/

Пакеты для тестирования компонентов
Эти пакеты связаны с экспериментальной системой тестирования компонентов в Playwright. Они предоставляют функциональность, аналогичную тому, как Jest может рендерить отдельные компоненты для разных библиотек.
✳️playwright-ct-core/
✳️playwright-ct-react/
✳️playwright-ct-react17/
✳️playwright-ct-solid/
✳️playwright-ct-svelte/
✳️playwright-ct-vue/
✳️playwright-ct-vue2/

Основные функциональные пакеты
Наконец, мы подходим к основным пакетам #Playwright, которые содержат всю главную функциональность проекта.
✳️playwright-core/
✳️playwright-test/
✳️playwright/
✳️protocol/

Обратите внимание, что папка playwright-test — это просто обёртка для связывания playwright-core и playwright вместе в пакете @playwright/test, устанавливаемом через npm. Если вы посмотрите в файл index.js, вы увидите только экспорт из playwright/test, который находится в пакете playwright.

Другой пакет, на который стоит обратить внимание, — это protocol, который содержит автоматически сгенерированный код через некоторые скрипты сборки в директории utils корневой директории проекта Playwright. Он содержит YAML-файл protocol.yml, который перечисляет все интерфейсы, используемые протоколом Playwright. Если вы когда-либо захотите создать драйвер для Playwright на другом языке, это один из основных файлов, к которому стоит обратиться при создании этой библиотеки.

Теперь два основных пакета всей библиотеки Playwright — это playwright и playwright-core. Первый из них является обёрткой вокруг playwright-core и отвечает за управление всей логикой тестирования. Это включает запуск рабочих процессов тестирования, выполнение тестов, отчёты о результатах, управление повторными запусками и утверждениями тестов. Хорошим ориентиром для кода, содержащегося в этом пакете, является любая конфигурационная логика, которую вы найдёте в файле playwright.config.ts, или любой связанный с запуском тестов код, например:

// my-test.spec.ts
import { test } from "@playwright/test";

В этом случае вы, вероятно, импортируете код из пакета playwright.

Другой основной пакет — playwright-core, который содержит всю функциональность автоматизации браузера. Эта функциональность разделена на два основных компонента: клиентскую библиотеку и серверную библиотеку. Серверная библиотека, находящаяся в packages/playwright-core/src/server, содержит всю логику, отвечающую за действия автоматизации браузера. Это означает, что она отправляет команды через Chrome DevTools Protocol (CDP) или аналогичные протоколы, чтобы сообщить браузеру выполнить такие действия, как "нажать кнопку входа", "ввести 'Hello' в текстовое поле" или "перейти на 'https://news.ycombinator.com'". Серверная библиотека содержит реализации для каждого из поддерживаемых браузеров и предоставляет унифицированный API через WebSocket-сервер для доступа к этой функциональности из других процессов.

С другой стороны, клиентская библиотека содержит все пользовательские API, которые вы используете при написании скриптов автоматизации браузера. Например, если у вас есть такой скрипт:

// my-automation-noscript.ts
import { chromium } from "@playwright/test";

(async function () {
  const browser = await chromium.launch({ headless: false });
  const page = await browser.newPage();
  await page.goto("https://playwright.dev");
})();

Вы фактически импортируете chromium из экземпляра класса в playwright-core/client/playwright.

Затем вызовы browser.newPage и page.goto делают запросы к интерфейсам в серверной библиотеке, которая взаимодействует с браузерами через CDP или аналогичные протоколы. Это означает, что если вы когда-либо захотите написать собственный инструмент автоматизации браузера, независимый от конкретного браузера, полезной отправной точкой будет использование серверной библиотеки из пакета playwright-core, поскольку она предоставляет всесторонний и проверенный API для такой функциональности.

Такой принцип разделения ответственности работает хорошо, потому что позволяет поддерживать несколько языков, которые могут использовать API автоматизации браузера Playwright. Фактически, если вы посмотрите на другие реализации библиотеки Playwright, вы обнаружите те же шаблоны проектирования (например, ChannelOwner), что и в клиентской библиотеке, найденной в playwright-core.

Перевод

Еще интересные статьи про архитектуру playwright:
➡️https://qacomet.com/playwright/how-playwright-initializes/
➡️https://medium.com/@divyarajsinhdev/understanding-playwright-architecture-e456fcee0222

Полезно? Ставьте 👍 👎

🤓 Всем привет!
Октябрь и ноябрь выдался на события⬇️
✅ Организовали непростой митап с РТК ИТ

✅ Побывал на гейзенбаге в новой для себя роли — в качестве эксперта, выступил на открытом микрофоне.
Прямо на конференции получил новость о том, что мою должность сокращают😑 Теперь я в активном поиске 🐆🐆

✅ Выступил с докладом на SQA Days про то, как меняется код QA-инженера в зависимости от грейда

✅ Организовали MoscowQA с VK Tech


Планы на оставшийся ноябрь также грандиозные:
📌 еду на любимую фронтовую конференцию HolyJs, если успею подготовить доклад, выступлю на открытом микрофоне.

📌 после Holy выступаю с докладом на митапе Qaчественое общение про репортеры в playwright

📌 на следующей неделе в книжном клубе сообщества MoscowQA будем обсуждать книгу «Принципы юнит-тестирования». Подробности на канале сообщества. Подписывайтесь, если хотите участвовать в мероприятиях и митапах MoscowQA😎

📌 в ближайшее время планирую запустить свой подкаст. И даже записал первый выпуск🤓 Но чтобы анонсировать, хочу иметь в запасе 4 выпуска🤠
Какие темы было бы интересно поднять?❓

#breakingnews

Ох, раньше я обожал собеседования…🗣

Но после того, как за последний месяц прошел их столько, что уже голова кругом, чувствую, что хватит. Поэтому решил: будет много разборов вопросов с собеседований, но не в формате «вопрос-ответ». Я готовлю небольшие статьи, где в одном тексте отвечаю сразу на 2-3 популярных вопроса.

Например:
✅ Что такое браузерный движок и зачем он нужен?
✅ Какие браузерные движки существуют?
✅ Основные этапы рендеринга страницы?
✅ Как работает JavaScript в браузере?
✅ Какие движки JavaScript существуют?
✅ В чем разница между браузерным движком и JavaScript движком?

В браузере есть два ключевых компонента:
❗️Браузерный движок (Rendering Engine)
❗️Движок JavaScript (JavaScript Engine)

🌐Браузерный движок
«Мозг» браузера, который превращает HTML и CSS в красивую картинку на экране.
Его этапы работы:
🟡Парсинг HTML и CSS (dom и cssom)
🟡Создание рендер-дерева
🟡Компоновка (layout)
🟡Отрисовка (painting)
🟡Выделение слоев (compositing)

Примеры движков:
🟡Blink (Chrome, Edge, Opera, Яндекс.Браузер)
🟡Gecko (Firefox)


📶Движок JavaScript
Отвечает за выполнение JS-кода, включая парсинг и оптимизацию.

Примеры движков:
🔵V8 (Google Chrome, Microsoft Edge)
🔵SpiderMonkey (Mozilla Firefox)
🔵JavaScriptCore (Nitro) (Safari)

Основные этапы работы (на примере V8):
1️⃣ Парсинг: создание AST (Abstract Syntax Tree).
2️⃣ Генерация байт-кода: промежуточное представление, которое проще
интерпретировать.
3️⃣Интерпретация: выполнение байт-кода.
4️⃣ JIT-компиляция: профилирование и компиляция часто вызываемого кода в машинный.

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

Подробнее о том как работает v8 смотрите ➡️ на Хабре.

Фремворк vs библиотека 🙌

В чем разница между библиотекой и фреймворком?👀

Если коротко и просто👇

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

📌 Фреймворк — это уже целая структура, которая задаёт правила и порядок работы. Вы добавляете свой код внутрь этой структуры, но основная логика и жизненный цикл уже управляются фреймворком.


Представьте стройку 🔨
🛠 Библиотека — это как набор инструментов: молоток, пила, шуруповёрт. Вы решаете, какие из них и когда использовать.

🏠 Фреймворк — это как готовый каркас дома. Вам остаётся добавить окна, двери и мебель, но основные правила и процесс строительства уже заданы.


Playwright как пример:
Playwright сам по себе — это библиотека. Он предоставляет API для управления браузерами (запуск, навигация по страницам, работа с элементами). Вы решаете, как и где его использовать, а сам Playwright не навязывает структуру.

Playwright Test — это уже фреймворк. Он добавляет тестовый раннер, готовый жизненный цикл тестов, параллельный запуск, ассерты и отчёты. С ним вам не нужно думать о базовой организации тестов — фреймворк берёт это на себя.


Ключевое различие👇
В библиотеке вы управляете всем сами. В фреймворке — вы следуете его правилам и структуре.

Какие еще примеры библиотеки/фреймворка знаете?🤔