Беспорядок: не учтите функциональные испытания, которые покрывают ту же землю как модульные тесты?
Чтобы добавить немного больше, убедитесь, что если вы собираетесь заблокировать вызов с помощью should_receive, у вас есть интеграционный тест, проверяющий, что вы действительно вызываете метод правильно.
Я был несколько раз, меняя метод, который был протестирован в другом месте, с must_receive, и тесты все еще проходили, когда вызов метода был прерван.
Если вы предпочитаете проверять результат, а не использовать should_receive, у musta есть хороший инструмент для сопоставления, который работает следующим образом:
it { should have_sent_email.with_subject(/is spam$/) }
Дополнительная информация об использовании musta Matchers с rSpec
2 ответа
Функциональный тест: выполняет ли он то, для чего маркетинг / удобство использования / клиенты подписаны ? то есть, если в вашей спецификации конкретно указано, что текстовое поле ZIP допускает только действительные почтовые индексы США, вам, вероятно, следует проверить это в функциональном тесте.
Unit Test: Выполняет ли он то, что разработчик ожидает от него. делать? В этих тестах вы должны использовать тестовые двойники , чтобы изолировать код от зависимостей.
Так что да, будет некоторое перекрытие.
Я бы, например, «увеличил» функциональность с помощью функциональных тестов и не беспокоился о том, чтобы охватить все, а вместо этого сосредоточился бы на модульных тестах.
Причины:
- функциональные тесты медленные
- функциональные тесты сложно писать и поддерживать
- функциональные тесты могут обнаруживать только два дополнительных элемента, помимо модульных тестов:
- Ошибки графического интерфейса
- межуровневые несоответствия
В общем, я обнаружил, что не окупается, если покрывать все дважды.