Мы, разработчики, часто по умолчанию создаем тестовый файл для каждого файла реализации. Это отнимает много полезных инструментов и опций, которые мы можем использовать для улучшения дизайна наших тестов.
Рассмотрим следующий пример тестирования рабочего процесса создания и проверки подлинности пользователя.
Обратите внимание на использование bcrypt.hash() в create-user.js и authenticate-user.test.js, а также использование bcrypt.compare() в authenticate-user.js и create-user.test.js.
При отдельном тестировании createUser и authenticateUser оба теста должны взаимодействовать с bcrypt. Тест для authenticateUser должен дублировать логику из createUser, а тест для createUser должен дублировать логику из authenticateUser.
Тестирование на этом уровне полезно для проверки того, что реализация использует bcrypt правильно, но такое использование, вероятно, скопировано из документации и не подвержено ошибкам.
Рассмотрим немного другой подход.
Дублирование кода между реализацией и тестом было уменьшено. Этот тест менее связан с bcrypt в качестве детали реализации. Этот тест также лучше отражает то, как createUser и authenticateUser следует использовать в другом месте кодовой базы.
Один тестовый файл на файл реализации — предположение по умолчанию, на которое стоит обратить внимание.
