Вкатываемся в NodeJS Help

Testing

Цель тестирования - проверка соответствия ПО предъявляемым требованиям. Если есть автотесты, то мы заведомо делаем так, что наше приложение будет всегда проверяться на актуальность.

Регрессионное тестирование - тестирование при котором мы не тестируем новый функционал, а тестируем старый что бы убедиться что мы ничего не сломали.

Виды тестов

  • Функциональные

    • е2е

    • интеграционные

    • unit

    • скриншотные (для фронтов)

  • Нефункциональные

    • нагрузочное тестирование

    • тестирование безопасности

    • регрессионное тестирование

  • Unit тесты (модульные) - Пишутся на какие-то независимые маленькие кусочки системы, такие как хелперы, методы и тд

  • Интеграционные тесты - Тесты при которых мы что-то тестируем в связке, т.е. несколько методов вместе(прим).

  • е2е - тест полность целого приложения. Проверяем какую-то ключевую функциональность, например авторизацию, оплату и тд. Все компаненты работают в связке, т.е все приложение. Работа с реальными данными и со всеми возможными случаями.

Процентное распределение тестов

  • е2е - 10%

  • интеграционные - 20-30%

  • unit - 70-80%

Как писать тест кейсы?

1 тест кейс всегда должен быть на правильный результат. 2 тест кейс всегда должен быть на пограничных значениях. 3 тест кейс всегда должен быть на невалидные данные.

Библиотеки для тестирования

  • Jest (позволяет писать unit test's)

  • cypress (для e2e (end-to-end) тестов)

  • loki (для скриншотных)

Паттерны тестирования

  • Stub

  • tdd

  • ddt

TDD (test driven development) - Тесты первее кода (достаточно редкая практика. За все свои проекты ни разу не встречал этот подход). В основе TDD лежит 5 основных этапов:

  1. Сначала разработчик пишет несколько тестов.

  2. Затем разработчик запускает эти тесты и (очевидно) они терпят неудачу, потому что ни одна из этих функций еще не реализована.

  3. Далее разработчик действительно реализует эти тесты в коде.

  4. Если разработчик хорошо пишет свой код, то на следующем этапе он увидит, что тесты проходят.

  5. Разработчик может затем реорганизовать свой код, добавить комментарии так как он уверен, что если новый код что-то сломает, тогда тесты предупредят об этом.

Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за «стаба», а вот из-за мока может.

Behavior-driven development (BDD) — подход создан для того, чтобы исправить проблемы, которые могут возникнуть при использовании ТDD, а именно, обеспечить лучшее взаимопонимание внутри команды, т.е. не только для разработчиков, облегчить поддержку кода через наглядное представление о его функциональности, тесты и их результаты выглядят более “человечно”, облегчается процесс миграции при переходе на другой язык программирования.

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

Это, по сути, создание плана перед тем, как вы начинаете писать код.

Стабы — объекты, также называемые_заглушками_, которые возвращают заранее определенные значения на определенные входные данные.

Last modified: 10 July 2025
AgileSOLID