Модульный тест должен проверять поведение единицы работы.
Модульные тесты изолированы и независимы друг от друга.
Модульные тесты — это легкие тесты:
- Повторяемый
- Быстрый
- Последовательный
- Легко писать и читать
- Любое данное поведение должно быть указано в одном и только одном тесте
- Выполнение/порядок выполнения одного теста не может влиять на другие
Окончательные рекомендации, которые мне очень помогли.
- По возможности используйте TDD
- Правильно структурируйте тесты
- Назовите свои тесты правильно
- Не комментируйте тесты
- Избегайте логики в тестах
- Не пишите ненужных ожиданий
- Знайте API своего тестового фреймворка
- Рассмотрите возможность использования фабричных функций в тестах
- Не проверяйте несколько проблем в одном тесте
- Покройте общий случай и пограничные случаи
- Тестируйте поведение, а не внутреннюю реализацию
- Не издевайся над всем
- Создавайте новые тесты для каждого дефекта
- Протестируйте простые действия
- Сначала просмотрите тестовый код
- Применяя TDD, всегда начинайте с написания простейшего теста на ошибку.
- Применяя TDD, всегда делайте небольшие шаги в каждом цикле «сначала тест».
- Правильно настройте действия, применимые ко всем задействованным тестам.
Помните 👉 «Модульные тесты — это тоже код»
Посмотрите, что сказал Бен на изображении ниже👇
Наш модульный тест должен быть таким.
Они должны соответствовать тому же уровню качества, что и тестируемый код.
Их также можно реорганизовать, чтобы сделать их более удобными в сопровождении и/или читабельными.
Несколько замечательных ресурсов:
Хорошие практики модульного тестирования JS и ужасные ошибки
Юнит-тестирование — отстой (и это наша вина)
Написание отличных модульных тестов: лучшие и худшие практики
Написание тестируемого JavaScript
Наиболее используемые библиотеки:
Надеюсь, вам понравится этот.
Спасибо за чтение.
Если вы постоянный читатель, спасибо, вы во многом помогли мне поделиться с вами своим жизненным/карьерным опытом.
Свяжитесь со мной в Twitter