WSDL.exe - Genera interfaz así como clase concreta para fake/mocks fácil más adelante

Question

¿Es posible hacer que WSDL.exe genere interfaces así como, o en lugar de, clases concretas cuando genera proxys a 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 contenedor y en las 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.

Pude 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é que editar manualmente la interfaz y las clases generadas automáticamente, que nunca Parece una buena idea.

¿Cuál es la forma más elegante de falsificar 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?

Answer 1

Right, provocado por La respuesta de Philip partí en una, y pude haber encontrado una solución funcional. Utilizando WSDL.exe genere las interfaces (usando el modificador/si) y clases proxy normales, y agregué ambas 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 (simulaciones o falsificaciones) que implementan la interfaz, y sustituirlas en lugar de la clase "shim".

Edit: OK, he trabajado un poco más en esto, y salvo algunas complicaciones, está funcionando.

El primer problema importante es que las clases proxy todavía están marcadas como "internas", por lo que la clase derivada (adaptador/shim) tiene que ser interna también.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 establecimos 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 siendo muy bueno para mí al probar y desarrollar 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 en un poco más detalle aquí: http://www.flowerchild.org.uk/archive/2010/09/21/mocking-or-faking-or-maybe-stubbing-a-wsdl-exe-soap.html

Answer 2

Puede ejecutar wsdl con el conmutador /serverinterface o /si 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.

EDIT - Después de leer el comentario, creo que he entendido mal la pregunta - desea la interfaz del cliente/concreto para que pueda codificar para contratar no implementación. El interruptor /si probablemente no le dará lo que desea en absoluto.

No conozco ningún modificador que pueda darle este comportamiento, ya que wsdl básicamente crea una de estas 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)

Answer 3

Siempre he encontrado que estas clases generadas son demasiado grandes como para burlarse con facilidad (demasiados métodos/propiedades).

Más bien, crear una fachada o un repositorio que implementa sólo las llamadas que necesita, y pasa de nuevo estilo de objetos DTO con sólo las propiedades que le interesan.

escribir algunas pruebas de integración simples contra el servicio web real y, a continuación, se burlan de la fachada más simple en el resto de las pruebas.

un añadido ventaja de este enfoque es que efectivamente obtener una capa de lucha contra la corrupción, por lo que los cambios en la tercera parte sólo tendrán un impacto en un área pequeña de su código.