💻Как cделать тестирование кода более эффективным: принципы FIRST

В последнее время я все больше уделяю внимание юнит тестированию, что связано с моим наставничеством на Hexlet и выравнивание пирамиды на работе.

И немного решил освежить основы при написания юнит тестов:
1️⃣ Быстрота (Fast): Тесты должны выполняться очень быстро. Время выполнения, включая настройку, сам тест и завершение, должно составлять миллисекунды, так как в проекте может быть тысячи тестов.
2️⃣ Изоляция (Isolated/Independent): Каждый тест должен быть независим. Он должен следовать модели "подготовка, действие, проверка" (Arrange, Act, Assert) без зависимости от других тестов или внешнего окружения.
3️⃣Повторяемость (Repeatable): Тесты должны давать одинаковые результаты в любой среде и в любое время, независимо от внешних условий, таких как дата/время или случайные значения.
4️⃣ Самодостаточность (Self-Validating): Результаты теста должны быть ясны без внешних проверок — тест либо проходит, либо нет, без всякой необходимости в дополнительной интерпретации.
5️⃣Тщательность (Thorough/Timely): Тесты должны охватывать все возможные сценарии использования и граничные условия, не ограничиваясь простым стремлением к 100% покрытию кода. Важно тестировать различные объемы данных, безопасность, и корректную обработку исключений.

Теги: #unitTests #testing

Рассказал о MemLab (спойлер: это инструмент для анализа и оптимизации потребления памяти вашими веб-приложениями) ➡️читать здесь.

Ранее уже писал о потреблении памяти веб-приложения:
🔵часть 1
🔵часть 2

👍 — если полезно, 👎 — ничего нового

Теги: #tools

🤓 Всем привет!
Я решил более регулярно вести канал, и мне интересно, что вам интересно и в каком виде — поучаствуйте в опросе, а если что-то хочется добавить, напишите в комментариях👇

🟢Что такое юнит тест? 🧩

🔎 Юнит тест — это тест, который проверяет правильность работы небольшого фрагмента кода (юнита).

🚩Особенности юнит тестов
1️⃣. Проверка небольших фрагментов кода.
2️⃣. Быстрая проверка.
3️⃣. Изоляция от остального кода.

🔍 Способы изоляции кода в юнит тестах
Тесты можно разделить на две школы по способу изоляции кода:
🔵Детройтская школа (классический подход)
🔵Лондонская школа

📘 Классический подход:
☑️Юнит тесты проверяют код с минимальной изоляцией.
☑️Интеграция с реальными зависимостями.

🎓 Лондонская школа:
☑️Сильная изоляция кода.
☑️Использование заглушек и моков для имитации зависимостей.


⚖️ Разница в подходах
🔵 Классический подход: Реальные зависимости, меньше моков.
🔵 Лондонская школа: Полная изоляция, много моков и заглушек.


💻 Примеры кода
Тестируемый код

// orderService.js
class OrderService {
  constructor(paymentService) {
    this.paymentService = paymentService;
  }

  placeOrder(order) {
    if (this.paymentService.processPayment(order)) {
      return 'Order placed';
    } else {
      return 'Payment failed';
    }
  }
}

// paymentService.js
class PaymentService {
  processPayment(order) {
    // Логика обработки платежа
    return true; // Или false в случае ошибки
  }
}

Классический подход 📘

test('placeOrder returns "Order placed" when payment is successful', () => {
  const paymentService = new PaymentService();
  const orderService = new OrderService(paymentService);
  const order = { amount: 100 };

  const result = orderService.placeOrder(order);

  expect(result).toBe('Order placed');
});

Лондонская школа🎓

test('placeOrder returns "Order placed" when payment is successful', () => {
  const paymentService = { processPayment: jest.fn().mockReturnValue(true) };
  const orderService = new OrderService(paymentService);
  const order = { amount: 100 };

  const result = orderService.placeOrder(order);

  expect(result).toBe('Order placed');
  expect(paymentService.processPayment).toHaveBeenCalledWith(order);
});

💡Вывод:
Выбор подхода зависит от конкретного проекта и предпочтений команды.

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

🍔Метрика покрытия кода: ограничения и примеры

Метрика покрытия кода показывает, какая доля исходного кода была выполнена в тестах.

Однако стопроцентное покрытие кода не гарантирует идеальное качество или отсутствие ошибок. Давайте рассмотрим два основных типа метрик покрытия кода и их ограничения.

Типы метрик покрытия кода
1️⃣ Code Coverage (Покрытие кода)
2️⃣ Branch Coverage (Покрытие ветвей)

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

Пример:

const evaluate = (x) => {
    if (x > 10) {
        return "Greater";
    } else {
        return "Lesser";
    }
};

// Тесты
assert(evaluate(5) == "Lesser");

В этом примере тесты покрывают 50% строк кода.


Теперь рассмотрим пример рефакторинга кода:

const evaluateRefactor = (x) => (x > 10) ? "Greater" : "Lesser";

// Тесты
assert(evaluateRefactor(5) == "Lesser");

В этом примере тесты покрывают только одну строку, что соответствует 100% покрытия


Проблемы с таким подходом:
1️⃣ Тесты могут выполнять строки кода без проверки их корректности.
2️⃣ Тесты не обязательно покрывают все возможные крайние случаи.
3️⃣ Высокий процент покрытия может создать иллюзию надежности.

Branch Coverage
Branch Coverage измеряет отношение количества покрытых ветвей к общему количеству ветвей в коде. Ветви – это управляющие структуры, такие как if, switch, и циклы.

Пример:

const evaluate = (x) => {
    if (x > 10) {
        return "Greater";
    } else if (x < 5) {
        return "Lesser";
    } else {
        return "Equal";
    }
};

// Тесты
assert(evaluate(15) == "Greater");
assert(evaluate(3) == "Lesser");
assert(evaluate(7) == "Equal");

В этом примере тесты покрывают все возможные ветви: if (x > 10), else if (x < 5) и else. Таким образом, достигается стопроцентное покрытие ветвей. Однако это не гарантирует, что все граничные условия, такие как точные значения 10 и 5, были протестированы.

Проблемы с таким подходом:
1️⃣ Неполное покрытие сценариев
2️⃣ Упущенные граничные случаи

Заключение:
➡️Метрика покрытия кода, будь то code coverage или branch coverage, является полезным инструментом, и они могут говорить о проблемах
➡️Низкие показатели говорят о проблема с тестами, однако высокие показатели не гарантируют что с тестами все в порядке
➡️Метрики покрытия - начальный этап на пути к хорошим тестам.

Ставьте 👍 👎

Теги: #code_coverage #branch_coverage #automation

✋Cors и как его обойти

Представьте, что вы тестируете веб-приложение. Ваше приложение может обращаться к данным с другого сервера (например, API или статики). Однако, по умолчанию браузеры блокируют такие запросы, если они идут с одного домена на другой.

Access to fetch at 'https://api.example.com/data' from origin 'https://myapp.com' 
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present 
on the requested resource.

🔎CORS (Cross-Origin Resource Sharing) позволяет настроить разрешения, чтобы ваш браузер мог безопасно запрашивать данные с других доменов.

Если CORS настроен неправильно, вы можете столкнуться с ситуацией, когда ваш тестируемый веб-сайт пытается получить данные с другого домена, а браузер блокирует запрос. Вы увидите ошибку в консоли разработчика, что "доступ запрещен из-за политики CORS".

Как обойти CORS при тестировании?
Иногда, для тестирования или разработки, нужно временно обойти CORS. Вот несколько способов:

1️⃣ Запуск браузера без проверки CORS:
🟣Вы можете запустить Chrome с флагом -disable-web-security, чтобы отключить проверку CORS. Это быстрое решение, когда вам нужно протестировать что-то без лишних препятствий.
🟣Например, запустите Chrome с командой:
➡️На Windows: start chrome --disable-web-security --user-data-dir="C:/chrome_dev"
➡️На macOS: open -na "Google Chrome" --args --disable-web-security --user-data-dir="/tmp/chrome_dev"

2️⃣ Использование прокси-сервера(fiddler, charles):
🟣Вы можете настроить прокси-сервер, который будет делать запросы к другому домену от имени вашего приложения. Таким образом, ваш браузер общается только с вашим сервером, и CORS не мешает.

3️⃣ Установка расширений для браузера:
🟣Есть расширения для Chrome и других браузеров, которые позволяют временно отключить проверку CORS. Однако их стоит использовать с осторожностью.

4️⃣Настройка CORS на сервере:
🟣Если у вас есть доступ к серверу, с которого делаются запросы, можно настроить его так, чтобы он разрешал запросы с вашего домена, добавив правильные заголовки CORS. Например, Access-Control-Allow-Origin: * разрешает запросы со всех доменов.

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

Ставьте 👍 👎
Теги: #cors #security #tools

🖥Тестирование тригеров GTM

Если вы занимаетесь тестированием веб-сайтов, то, вероятно, вам приходилось тестировать триггеры в Google Tag Manager и отправлять события аналитики.

Почему это важно? Дело в том, что большинство таких событий имеют прямое отношение к маркетингу. Маркетологи используют различные метрики продаж, чтобы понять, как лучше продавать. В общем, это напрямую связано с деньгами.💸

Как тестировать события❕❕

1⃣ для ручного тестирования и самый удобный способ это использовать https://tagassistant.google.com/
Там просто вставляете url, и проходите тест кейсы, а в другом окне наблюдаете события (рекомендуем)

2⃣ Использовать консоли разработчика
все события пушится в переменную dataLayer

3⃣ Тестирование через Network-панель браузера, можно наблюдать был ли отправлен запрос на нужный сервер (например, на сервер Google Analytics).


Для автоматизированного тестирования на Playwright, вы можете использовать несколько подходов👇

*️⃣ отслеживание через запросы

test('Track network request and verify payload', async ({ page }) => {
  await page.goto('https://your-website.com');

  // Перехват и проверка сетевых запросов
  const [response] = await Promise.all([
    page.waitForResponse(response => response.url().includes('www.google-analytics.com/collect') && response.status() === 200),
    // Выполняем действие на странице, которое должно вызвать запрос
    page.click('button')
  ]);

  const requestPayload = JSON.parse(response.request().postData());

  expect(requestPayload).toHaveProperty('event', 'yourExpectedEvent');
  expect(requestPayload).toHaveProperty('gtm', 'expectedGtmId');
});

*️⃣проверка данных в dataLayer

test('Check dataLayer for specific event', async ({ page }) => {
  await page.goto('https://your-website.com');

  // Выполняем действие на странице
  await page.click('button#yourButton');

  // Получаем значение dataLayer из контекста страницы
  const dataLayer = await page.evaluate(() => window.dataLayer);

  // Проверка, что dataLayer содержит ожидаемое событие
  const eventData = dataLayer.find(event => event.event === 'yourExpectedEvent');

  expect(eventData).not.toBeNull();
  expect(eventData).toHaveProperty('gtm', 'yourExpectedGtm');
});

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

Ставьте 👍 👎


Теги: #testing #playwright #automation #dataLayer #GTM #тестирование #разработка

#дайджест 📢


⚡️ В nodeJS 22.6 добавили поддержку typenoscript

⚡️ Playwright в 👩‍💻 версии **1.46
🌟 позволяет указывать клиентские сертификаты, теперь не надо игнорировать https
🌟 новая опция CLI --only-changed позволяет запускать только тестовые файлы, которые изменились с момента последней фиксации git
🌟 Обновление UI Mode / Trace Viewer
🌟 В APIRequestContext.fetch() появилась новая опция maxRetries. Она позволяет повторять попытку при возникновении сетевой ошибки ECONNRESET.
🌟 Опция Box в фикстурах уменьшает мусор в отчетах

⚡️👩‍💻 k6 v0.53.0
Добавили поддержку нативных ECMAScript модулей
и другие улучшения

⚡️ WebdriverIO 👩‍💻 v9
Все сеансы будут автоматически использовать протокол Bidi
Подробнее

Теги: #updates