Модульный тест должен проверять поведение единицы работы.

Модульные тесты изолированы и независимы друг от друга.

Модульные тесты — это легкие тесты:

  • Повторяемый
  • Быстрый
  • Последовательный
  • Легко писать и читать
  • Любое данное поведение должно быть указано в одном и только одном тесте
  • Выполнение/порядок выполнения одного теста не может влиять на другие

Окончательные рекомендации, которые мне очень помогли.

  • По возможности используйте TDD
  • Правильно структурируйте тесты
  • Назовите свои тесты правильно
  • Не комментируйте тесты
  • Избегайте логики в тестах
  • Не пишите ненужных ожиданий
  • Знайте API своего тестового фреймворка
  • Рассмотрите возможность использования фабричных функций в тестах
  • Не проверяйте несколько проблем в одном тесте
  • Покройте общий случай и пограничные случаи
  • Тестируйте поведение, а не внутреннюю реализацию
  • Не издевайся над всем
  • Создавайте новые тесты для каждого дефекта
  • Протестируйте простые действия
  • Сначала просмотрите тестовый код
  • Применяя TDD, всегда начинайте с написания простейшего теста на ошибку.
  • Применяя TDD, всегда делайте небольшие шаги в каждом цикле «сначала тест».
  • Правильно настройте действия, применимые ко всем задействованным тестам.

Помните 👉 «Модульные тесты — это тоже код»

Посмотрите, что сказал Бен на изображении ниже👇

Наш модульный тест должен быть таким.

Они должны соответствовать тому же уровню качества, что и тестируемый код.

Их также можно реорганизовать, чтобы сделать их более удобными в сопровождении и/или читабельными.

Несколько замечательных ресурсов:

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

Юнит-тестирование — отстой (и это наша вина)

Написание отличных модульных тестов: лучшие и худшие практики

Написание тестируемого JavaScript

Наиболее используемые библиотеки:

Надеюсь, вам понравится этот.

Спасибо за чтение.

Если вы постоянный читатель, спасибо, вы во многом помогли мне поделиться с вами своим жизненным/карьерным опытом.

Свяжитесь со мной в Twitter