Ich habe es nie gemocht, Mocks zu schreiben und vor einiger Zeit hat hier jemand empfohlen, FakeWeb zu benutzen. Ich habe mich sofort in FakeWeb verliebt. Ich muss mich jedoch fragen, ob es einen Nachteil für die Verwendung von FakeWeb gibt. Es scheint, als ob Mocks immer noch viel häufiger sind, also frage ich mich, was ich vermisse, ist falsch mit FakeWeb stattdessen zu verwenden. Gibt es eine bestimmte Art von Fehlern, die Sie mit Fakeweb nicht abdecken können, oder ist es etwas über den TDD- oder BDD-Prozess?
Sie sollten sich WebMock Ссылка ansehen
Der Nachteil von verspotteten HTTP-Anfragen ist der fehlende Schutz vor Remote-API-Änderungen. Wenn sich der Remote-HTTP-Dienst ändert und Ihr Code nicht mehr kompatibel ist, werden Ihre Tests Sie nicht darüber informieren. Wenn Sie die HTTP-Client-Methoden selbst ausprobieren, haben Sie die gleichen Probleme. Es ist gut, eine Integrationstest-Suite zu haben, die überprüft, ob Ihr Code immer noch mit einem echten http-Dienst kommunizieren kann.
Der Vorteil einer Bibliothek wie FakeWeb oder WebMock ist die Tatsache, dass Sie sich auf das Implementieren von Verhalten konzentrieren können, anstatt sich über Implementierungsdetails einer bestimmten HTTP-Client-Bibliothek Gedanken zu machen. Selbst wenn Sie die Bibliothek beispielsweise von Net :: HTTP in RestClient ändern, sollte das Verhalten dennoch beibehalten werden, damit die Tests weiterhin bestehen. Wenn Sie den HTTP-Client selbst verspotten, müssen Sie die Tests ändern, wenn Sie die Implementierung ändern, selbst wenn sich das Verhalten nicht geändert hat. Die Verwendung von FakeWeb oder Webmock hilft auch bei TDD oder BDD (zuerst testen). Sie können das HTTP-Verhalten mit Spezifikationen oder Tests angeben, bevor Sie sich über Implementierungsdetails eines bestimmten http-Clients Gedanken machen.
Sie werden wahrscheinlich mit VCR zufrieden sein, einem Wrapper um HTTP-Mocking-Bibliotheken. Es speichert die ursprünglichen HTTP-Anforderungen, so dass Ihre Tests schnell sind und offline arbeiten. Sie können jedoch auch geändert werden, um die ursprüngliche Anforderung erneut auszuführen, um zu sehen, ob der Test mit der Remote-API funktioniert.
Tags und Links unit-testing ruby-on-rails mocking fakeweb