.net - WSDL.exe: genera interfaz y clase concreta para simular falsificaciones/burlas más tarde
testing soap (3)
¿Es posible hacer que WSDL.exe genere interfaces así como, o en lugar de, clases concretas cuando genera proxys para un servicio web?
Estamos consumiendo un servicio web de terceros desde una aplicación ASP.Net, y hemos generado nuestras clases de proxy utilizando WSDL.exe todo muy bien.
Ahora quiero escribir pruebas en mi envoltorio y clases de negocios falsificando el servicio web. No hay ninguna interfaz o clase base abstracta para el proxy, y están marcadas como internas, lo que significa que no puedo heredar de ellas sin poner mi código de prueba falso / simulado en mi proyecto / ensamblado empresarial.
Podía crear manualmente una interfaz (usando resharper) y editar la clase; sin embargo, si la tercera parte cambia su WSDL / servicio web, yo o mis sucesores también tendrían que editar manualmente la interfaz y las clases generadas automáticamente, lo que nunca parece una buena idea.
¿Cuál es la manera más elegante de fingir o burlarse de este servicio? ¿Debería poner la falsificación en el proyecto empresarial? ¿Debo editar manualmente los archivos y crear una interfaz? ¿Debo hacer algo completamente diferente?
Correcto, motivado por la respuesta de Philip, partí en uno, y pude haber encontrado una solución funcional. Usando WSDL.exe genere las interfaces (usando el conmutador / si) y las clases proxy normales, y las agregué a mi proyecto empresarial.
Luego creé una nueva clase que hereda de la clase concreta Y implementa la interfaz. Esta pequeña clase no contenía básicamente ningún código, ya que los miembros concretos heredados proporcionaban una implementación implícita de los miembros de la interfaz. El código compilado por primera vez y he podido sustituir esta pequeña clase "shim" (? Adapter?) En mis pruebas de integración y ejecutar llamadas contra el servidor de terceros en vivo.
Ahora puedo crear otras clases (simulacros o falsificaciones) que implementan la interfaz y sustituirlas en lugar de la clase "shim".
Editar: OK, he trabajado un poco más en esto, y salvo algunas complicaciones, está funcionando.
El primer problema importante es que las clases proxy aún están marcadas como "internas", por lo que la clase derivada (adaptador / shim) también debe ser interna. Esto no es un problema si coloca una clase de fábrica en su proyecto / ensamblado de negocio que actualiza las clases de proxy y las devuelve como la interfaz.
El segundo problema que encontré fue que estábamos estableciendo explícitamente las propiedades URL y tiempo de espera de la webserice, pero estas no están incluidas en la interfaz sino que se heredan de System.Web.Services.Protocols.WebClientProtocol a través de SoapHttpClientProtocol. Una vez más, traté esto en la fábrica, ya que es un detalle de implementación que estoy feliz de no estar en la interfaz.
Editar: Esto sigue funcionando muy bien para mí mientras pruebo y desarrollo nuestra Fachada. Desde que obtuve el proxy detrás de una interfaz, también he creado una clase de decorador de registros, que está capturando muchas llamadas de ejemplo para la depuración de uso, y cuando el servidor de terceros está fuera de línea.
He escrito lo que hice con un poco más de detalle aquí: http://www.flowerchild.org.uk/archive/2010/09/21/mocking-or-faking-or-maybe-stubbing-a-wsdl -exe-soap.html
Siempre he encontrado que estas clases generadas son demasiado grandes para simular fácilmente (demasiados métodos / propiedad).
Más bien, cree una Fachada o Repositorio que implemente solo las llamadas que necesita, y devuelve los objetos de estilo DTO con solo las propiedades que le interesan.
Escribe algunas pruebas de integración simples contra el servicio web real, y luego simula la Fachada más simple en el resto de las pruebas.
Un beneficio adicional de este enfoque es que obtiene efectivamente una capa anticorrupción, por lo que los cambios en la tercera parte solo afectarán a un área pequeña de su código.
Puede ejecutar wsdl con /serverinterface o /si cambiar para obtener interfaces para cada enlace en el wsdl. Esto tiene la intención de proporcionarle el esqueleto del lado del servidor desde un documento wsdl, pero las interfaces deben ponerlo en su camino, si entiendo la pregunta correctamente.
EDITAR - Después de leer el comentario, creo que entendí mal la pregunta: quiere una interfaz de cliente / concreta para que pueda codificar para contratar, no para implementar. El /si probablemente no le dará lo que desea en absoluto.
No conozco ningún cambio que pueda darle este comportamiento, ya que wsdl básicamente crea una de tres cosas: 1) clases proxy de cliente: 2) clases abstractas de servidor (para crear una implementación de servidor) 3) interfaces de servidor (nuevamente, para crear una implementación de servidor: esto es solo iface en lugar de clase abstracta) No veo ninguna forma de forzar a las clases proxy del cliente a implementar interfaces (que no sean INotifyPropertyChanged en tipos de datos)