Оборотные стороны к использованию FakeWeb по сравнению с записью насмешек для тестирования
Мне никогда не нравилось писать насмешки, и только что кто-то здесь рекомендовал использовать FakeWeb. Я сразу полностью влюбился в FakeWeb. Однако я должен задаться вопросом, существует ли оборотная сторона к использованию FakeWeb. Кажется, что насмешки еще намного более распространены, поэтому интересно, что я пропускаю, это неправильно с использованием FakeWeb вместо этого. Существует ли определенный вид ошибки, которую Вы не можете покрыть Fakeweb или являетесь им что-то о процессе BDD или TDD?
1 ответ
Вам следует взглянуть на WebMock http://github.com/bblimke/webmock
Обратной стороной имитации HTTP-запросов является отсутствие защиты от удаленного изменения API. Если удаленная служба HTTP изменится, и ваш код больше не будет совместим, ваши тесты не сообщат вам об этом. Если вы имитируете методы HTTP-клиента самостоятельно, у вас будут те же проблемы. Хорошо иметь какой-нибудь набор интеграционных тестов, который проверяет, может ли ваш код по-прежнему взаимодействовать с реальной HTTP-службой.
Преимущество таких библиотек, как FakeWeb или WebMock, заключается в том, что вы можете сосредоточиться на реализации поведения, а не беспокоиться о деталях реализации конкретной клиентской библиотеки http. Даже если вы измените библиотеку, например, с Net :: HTTP на RestClient, поведение все равно должно сохраниться, поэтому тесты все равно должны проходить. Если вы имитируете http-клиент самостоятельно, вам придется изменить тесты при изменении реализации, даже если поведение не изменилось. Использование FakeWeb или Webmock также помогает с TDD или BDD (сначала проверьте). Вы можете указать поведение http с помощью спецификаций или тестов, прежде чем беспокоиться о деталях реализации конкретного клиента http.