ruby on rails - Desventajas del uso de FakeWeb en comparación con la escritura de simulacros para probar
ruby-on-rails unit-testing (2)
Deberías echarle un vistazo a WebMock http://github.com/bblimke/webmock
La desventaja de burlarse de las solicitudes http es la falta de protección contra los cambios de API remotos. Si el servicio HTTP remoto cambia, y su código ya no será compatible, sus pruebas no le informarán al respecto. Si se burla de los métodos de cliente http por su cuenta, tiene los mismos problemas. Es bueno contar con un conjunto de pruebas de integración que verifique que su código aún pueda comunicarse con el servicio http real.
La ventaja de una biblioteca como FakeWeb o WebMock es el hecho de que puede centrarse en implementar el comportamiento en lugar de preocuparse por los detalles de implementación de la biblioteca de cliente HTTP específica. Incluso si cambia la biblioteca de, por ejemplo, Net :: HTTP a RestClient, el comportamiento debería conservarse para que las pruebas sigan pasando. Si se burla del cliente http por su cuenta, debe cambiar las pruebas cuando cambie la implementación, incluso si el comportamiento no cambió. Usar FakeWeb o Webmock también ayuda con TDD o BDD (prueba primero). Puede especificar el comportamiento http con especificaciones o pruebas, antes de preocuparse por los detalles de implementación de un cliente HTTP específico.
Nunca me gustó escribir burlas y hace un tiempo alguien me recomendó usar FakeWeb. Inmediatamente me enamoré completamente de FakeWeb. Sin embargo, tengo que preguntarme si hay un inconveniente al usar FakeWeb. Parece que los simulacros todavía son mucho más comunes, así que me pregunto qué me está perdiendo que está mal con el uso de FakeWeb en su lugar. ¿Hay algún tipo de error que no se puede cubrir con Fakeweb o es algo sobre el proceso TDD o BDD?
Probablemente se sentirá satisfecho con la videograbadora, que es un contenedor de las bibliotecas de burla de HTTP. Almacena en caché las solicitudes HTTP originales, de modo que sus pruebas sean rápidas y sin conexión, pero también se puede modificar para ejecutar nuevamente la solicitud original, para ver si la prueba funciona en contra de la API remota.