На замену гермионе яндекс выпустил тестовый фреймворк Testplane
Основанный на wdio и mocha

🤔 Интересно там пофиксили баг со скриншотом айфрейма
Не знаю на сколько им пользуются, ссылку оставлю тут, вдруг кому интересно
https://github.com/gemini-testing/testplane
Теги: #testplane #wdio #mocha

💻Как 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