web services - script - Mocking WebService consumido por un puerto Biztalk Request-Response

soapui mock dispatch responses (7)

Estoy utilizando BizUnit para probar las unidades de mis orquestaciones de Biztalk, pero algunas orquestaciones consumen un servicio web, y probarlas parece más una prueba de integración que una unidad de prueba.

Estoy familiarizado con el uso de un marco burlón para simular los objetos proxy generados, con el fin de probar un servicio web desde una aplicación de Windows Forms, pero me gustaría poder hacerlo de una manera más integrada en un puerto de solicitud y respuesta ?

¿Cómo abordarías este problema?

No he tenido que hacer esto por un tiempo, pero cuando probaba mis aplicaciones Biztalk siempre usaba soap ui o estudio de servicio web. Pude probar diferentes valores de entrada sin esfuerzo.

Descargo de responsabilidad: yo trabajo en Typemock.

No estoy seguro de lo que debe hacer, pero creo que el siguiente enlace es un buen comienzo:

No lo hagas

No realice pruebas contra interfaces arbitrarias, y no cree burlas para ellas.

La mayoría de las personas parecen ver las pruebas de desarrollador (unidad) como destinadas a probar unidades de funcionalidad individuales no triviales, como una sola clase. Por otro lado, también es importante realizar pruebas de los clientes (aceptación / integración) de los principales subsistemas o de todo el sistema.

Para un servicio web, la unidad de funcionalidad no trivial está oculta en las clases que realmente realizan el servicio significativo, detrás del cableado de comunicación. Esas clases deben tener clases de prueba de desarrollador individuales que verifiquen su funcionalidad, pero completamente sin ninguno de los cables de comunicación orientados al servicio web. Naturalmente, pero quizás no obviamente, eso significa que su implementación de la funcionalidad debe estar separada de su implementación del cableado. Por lo tanto, sus pruebas de desarrollador (unidad) nunca deben ver nada de ese cableado de comunicación especial; eso es parte de la integración y puede verse (apropiadamente) como una cuestión de "presentación" en lugar de "lógica comercial".

Las pruebas del cliente (aceptación / integración) deben abordar una escala de funcionalidad mucho mayor, pero aún no se centran en problemas de "presentación". Aquí es donde el uso del patrón Fachada es común: exponer un subsistema con una interfaz comprobable unificada, de grano grueso. De nuevo, la integración de la comunicación del servicio web es irrelevante y se implementa por separado.

Sin embargo, es muy útil implementar un conjunto separado de pruebas que realmente incluyen la integración del servicio web. Pero recomiendo no probar solo un lado de esa integración: probarlo de extremo a extremo. Eso significa construir pruebas que son clientes de servicios web al igual que el código de producción real; Deben consumir los servicios web exactamente de la misma manera que lo hacen las aplicaciones reales, lo que significa que esas pruebas sirven como ejemplos para cualquiera que deba implementar dichas aplicaciones (como sus clientes si está vendiendo una biblioteca).

Entonces, ¿por qué ir a todos esos problemas?

Sus pruebas de desarrollador verifican que su funcionalidad funcione en la pequeña, independientemente de cómo se acceda (independientemente del nivel de presentación, ya que está dentro del nivel de lógica de negocios).
Las pruebas de sus clientes verifican que su funcionalidad funcione en general, de nuevo independientemente de cómo se acceda, en el límite de la interfaz de su nivel lógico de negocios.
Sus pruebas de integración verifican que su nivel de presentación funcione con su nivel lógico de negocio, que ahora es manejable, ya que ahora puede ignorar la funcionalidad subyacente (porque lo probó por separado anteriormente). En otras palabras, estas pruebas se centran en una capa delgada de una cara bonita (GUI?) Y una interfaz de comunicación (servicios web?).
Cuando agrega otro método para acceder a su funcionalidad, solo tiene que agregar pruebas de integración para esa nueva forma de acceso (nivel de presentación). Sus pruebas de desarrollador y cliente aseguran que su funcionalidad central no se modifique ni se rompa.
No necesita herramientas especiales, como una herramienta de prueba específicamente para servicios web. Utiliza las herramientas / componentes / bibliotecas / técnicas que usaría en el código de producción, exactamente como las usaría en dicho código de producción. Esto hace que sus pruebas sean más significativas, ya que no está probando las herramientas de otra persona. Le ahorra mucho tiempo y dinero, ya que no está comprando, implementando, desarrollando y manteniendo una herramienta especial. Sin embargo, si está probando a través de una GUI (¡no haga eso!), Es posible que necesite una herramienta especial para esa parte (p. Ej., HttpUnit?).

Entonces, pongámonos concretos. Supongamos que queremos proporcionar alguna funcionalidad para hacer un seguimiento del menú diario de la cafetería (porque trabajamos en un megacorpo con su propio café en el edificio, como el mío). Digamos que estamos apuntando a C #.

Construimos algunas clases de C # para menús, elementos de menú y otras funciones de granularidad fina y sus datos relacionados. Establecemos una compilación automatizada (¿lo haces, verdad?) Usando nAnt que ejecuta pruebas de desarrollador usando nUnit, y confirmamos que podemos construir un menú diario y mirarlo a través de todas estas pequeñas piezas.

Tenemos una idea de hacia dónde vamos, por lo que aplicamos el patrón Fachada creando una única clase que expone un puñado de métodos mientras oculta la mayoría de las piezas de grano fino. Agregamos un conjunto separado de pruebas de clientes que operan solo a través de esa nueva fachada, tal como lo haría un cliente.

Ahora decidimos que queremos proporcionar una página web para que nuestros trabajadores del conocimiento de megacorp revisen el menú de la cafetería de hoy. Escribimos una página ASP.NET, hacemos que invoque nuestra clase de fachada (que se convierte en nuestro modelo si estamos haciendo MVC) y la implementamos. Dado que ya hemos probado exhaustivamente la clase de fachada a través de nuestras pruebas de clientes, y dado que nuestra única página web es tan simple, renunciamos a escribir pruebas automatizadas contra la página web; una prueba manual con algunos compañeros trabajadores del conocimiento hará el truco.

Más tarde, comenzamos a agregar nuevas funcionalidades importantes, como poder preordenar nuestro almuerzo del día. Extendemos nuestras clases de grano fino y las pruebas de desarrollador correspondientes, sabiendo que nuestras pruebas preexistentes nos protegen contra romper la funcionalidad existente. Del mismo modo, ampliamos nuestra clase de fachada, tal vez incluso dividimos una nueva clase (por ejemplo, MenuFacade y OrderFacade) a medida que crece la interfaz, con adiciones similares a las pruebas de nuestros clientes.

Ahora, tal vez, los cambios en el sitio web (dos páginas son un sitio web, ¿no?) Hacen que las pruebas manuales sean insatisfactorias. Entonces, traemos una herramienta simple comparable a HttpUnit que le permite a nUnit probar páginas web. Implementamos una batería de pruebas de integración / presentación, pero en contra de una versión simulada de nuestras clases de fachada, porque el punto aquí es simplemente que las páginas web funcionan: ya sabemos que las clases de fachadas funcionan. Las pruebas empujan y extraen datos a través de las fachadas simuladas, solo para probar que los datos llegaron con éxito al otro lado. Nada mas.

Por supuesto, nuestro gran éxito impulsa al CEO a solicitar (exigir) que expongamos la aplicación web a los BlackBerry de megacorp. Entonces implementamos algunas páginas nuevas y una nueva batería de pruebas de integración. No tenemos que tocar las pruebas de desarrollador o cliente porque no hemos agregado ninguna funcionalidad principal nueva.

Finalmente, la CTO solicita (exige) que ampliemos nuestra aplicación de cafetería a todos los trabajadores robóticos de megacorp: ¿los notó en los últimos días? Entonces, ahora agregamos una capa de servicios web que se comunica a través de nuestra fachada. De nuevo, no hay cambios en nuestra funcionalidad principal, nuestras pruebas de desarrollador o nuestras pruebas de clientes. Aplicamos el patrón Adapter / Wrapper al crear clases que exponen la fachada con una API de servicio web equivalente, y creamos clases del lado del cliente para consumir esa API. Agregamos una nueva batería de pruebas de integración, pero usan nUnit simple para crear clases de API del lado del cliente, que se comunican a través del servicio web a las clases de API de servicio, que invocan clases de fachada falsas, que confirman que nuestro cableado funciona.

Tenga en cuenta que a lo largo de todo este proceso, no necesitamos nada significativo más allá de nuestra plataforma y código de producción, nuestra plataforma de desarrollo elegida, algunos componentes de código abierto para construcción y pruebas automatizadas y algunas baterías de pruebas bien definidas. También tenga en cuenta que no probamos nada que no utilicemos en producción, y no probamos nada dos veces.

Terminamos con un núcleo sólido de funcionalidad (nivel de lógica de negocios) que ha demostrado ser maduro (hipotéticamente). Tenemos tres implementaciones de nivel de presentación separadas: un sitio web dirigido a escritorios, un sitio web dirigido a BlackBerry y una API de servicio web.

Ahora, por favor, perdóneme por la respuesta larga: estoy cansado de las respuestas inadecuadas y no quería proporcionar ninguna. Y tenga en cuenta que he hecho esto (aunque no para un menú de cafetería).

Esta es la manera de hacerlo:

Volviendo a la pregunta de Richard, mi equipo de desarrollo anterior tenía una solución. Básicamente, lo que hicimos fue escribir un HttpHandler configurable genérico que analizara las solicitudes de servicio entrantes y devolviera las respuestas preestablecidas. La respuesta enviada fue configurable según condiciones como XPath

Como coautor de BizUnitExtensions (www.codeplex.com/bizunitextensions) estoy de acuerdo en que el nombre "unidad" en BizUnit puede ser confuso, pero para Biztalk, la ''prueba de integración'' es la prueba unitaria. Algunos usuarios de Biztalk han utilizado con éxito simulaciones para probar componentes de tuberías y otros arneses de prueba (+ BizUnit / Extensions) para probar esquemas y mapas.

Las orquestaciones lamentablemente son opacas. Pero hay buenas razones para eso.

(a) Debido al gran sistema de suscripción en el cuadro de mensaje, que las orquestaciones usan cuando se activan, etc., no es posible iniciar un proceso "virtual" para alojar la orquestación (lo que se puede hacer por las canalizaciones. Tomas Restrepo lo ha hecho algo en esta línea).

(b) Además, ¿cómo manejaría este proceso virtual la persistencia y la deshidratación ?. Apostaría a que las personas que usan WF tendrían el mismo problema al tratar de probar el flujo de trabajo por completo.

(c) no trabajamos directamente con C #, por lo que no hay forma de que podamos "inyectar" una interfaz simulada en el código de orquestación.

(d) Una orquestación no es realmente una "unidad". es un elemento compuesto. Las unidades son los mensajes que van hacia y desde el cuadro de mensaje y los componentes externos llamados a través de formas de expresión. Así que incluso si pudiera inyectar una interfaz de servicio web simulada, no puede inyectar cuadros de mensaje falsos y conjuntos de correlaciones y otras cosas.

Una cosa que se puede hacer para las orquestaciones (y he estado considerando una adición a la biblioteca BizUnitExtensions para hacer esto) es enlazar con la herramienta OrchestrationProfiler ya que esta herramienta proporciona un informe bastante detallado de todas las formas y de alguna manera verifica ese individuo se ejecutaron los pasos (y tal vez el tiempo que tardó en ejecutarse). Esto podría llegar muy lejos al hacer que la orquestación sea un poco más de un recuadro blanco. Considerando también que el depurador de orquestación muestra muchos de los valores variables, seguramente debe ser posible obtener esa información a través de una API para mostrar los valores de las variables estaban en un punto dado para una instancia determinada.

Volviendo a la pregunta de Richard, mi equipo de desarrollo anterior tenía una solución. Básicamente, lo que hicimos fue escribir un HttpHandler configurable genérico que analizara las solicitudes de servicios entrantes y devolviera las respuestas preestablecidas. La respuesta enviada fue configurable según condiciones como XPath. En los archivos de enlace BUILD y DEV, el punto final del servicio web era el simulacro. Esto funcionó brillantemente al aislar los entornos BUILD y DEV de los servicios web propios de terceros. Esto también ayudó en un enfoque de "contrato primero" donde construimos el simulacro y el desarrollador orch lo usó mientras el autor del servicio web siguió adelante y construyó el servicio real.

[Actualización: 17-FEB-09: esta herramienta está ahora en codeplex: http://www.codeplex.com/mockingbird . Si este enfoque parece interesante, échale un vistazo y cuéntame qué opinas de la herramienta]

Ahora, antes de que alguien arroje el viejo "WHAT ABOUT MÓDULOS OBJECT FRAMEWORKS", permítame decir que la utilidad anterior se utilizó tanto para los consumidores de Biztalk como para los consumidores que no son Biztalk, PERO también he trabajado con NMock2 y encontré que ser una excelente manera de burlarse de las interfaces y establecer expectativas al escribir consumidores de CLR. (Voy a buscar en MoQ y TypeMock, etc. pronto). Sin embargo, no funcionará con orquestaciones por los motivos descritos anteriormente.

Espero que esto ayude.

Saludos,

Benjy

Esto va al corazón de una de mis principales irritaciones como desarrollador de BizTalk: BizTalk no se presta a pruebas unitarias. Desde el hecho de que el 99% de sus interfaces en aplicaciones BizTalk se basan en mensajes y tienen una gran cantidad de posibles entradas, hasta la opacidad de las orquestaciones, BizTalk no ofrece una manera real de probar unidades de funcionalidad como ... bueno ... unidades.

Para BizTalk, las pruebas de integración son a menudo el único juego de la ciudad.

Eso da como resultado, debido a que no hay falta por parte de Kevin Smith, BizUnit siendo (IMO) un nombre inapropiado. Un nombre mejor sería quizás BizIntegrationIt. BizUnit ofrece una gama de herramientas que ayudan en las pruebas de integración, la mayoría de sus pruebas, como comprobar si un archivo se ha escrito en un directorio determinado o enviar una HTTPRequest a una ubicación de BizTalk HTTPReceive son estrictamente hablando, probando la integración.

Ahora que he sacado a relucir eso, lo que estás pidiendo es algo en lo que he estado pensando durante mucho tiempo, la capacidad de crear pruebas unitarias automatizadas que dan cierta confianza real de que hice un pequeño cambio en un mapa ganado De repente, se rompe algo más corriente abajo, así como una forma de eliminar la dependencia de los servicios externos.

Nunca he pensado en ninguna buena manera de hacerlo, pero a continuación hay una solución que debería funcionar, he hecho variaciones de cada parte de este en forma aislada, pero nunca intenté agruparlas en esta forma específica.

Por lo tanto, dado el deseo de burlar una llamada a algún servicio externo (que tal vez no exista aún) sin necesidad de realizar ninguna llamada externa y querer tener la capacidad de establecer expectativas para esa llamada de servicio y especificar la naturaleza de la respuesta, el único método que puedo pensar es desarrollar un adaptador personalizado.

Simula un servicio web usando un adaptador personalizado

Si construye un adaptador de solicitud-respuesta personalizado, puede conectarlo a su puerto de envío en lugar del adaptador SOAP. A continuación, puede especificar propiedades para el adaptador que le permitan comportarse como una burla de su servicio web. El adaptador sería similar en concepto a un adaptador de bucle invertido, pero permitiría la lógica de burla interna.

Cosas que podría querer incluir como propiedades de adaptador:

Documento esperado (tal vez una ubicación de disco que especifique un ejemplo de lo que espera que su aplicación BizTalk envíe al servicio web).
Documento de respuesta: el documento que el adaptador enviará de vuelta al motor de mensajería.
Expectativas específicas para la prueba, como los valores de búsqueda en los elementos del documento.

También podría hacer que el adaptador personalizado escriba en el disco y configurar un paso BizUnit para validar el archivo que se escribió.

Crear un adaptador personalizado no es trivial, pero es posible, puede obtener un buen comienzo del Asistente de Adaptador de BizTalk y hay un artículo sobre cómo implementar adaptadores personalizados aquí .

Hay un error en el código generado por el asistente, deberá cambiar el new Guid(""), al new Guid() .

También hay algunos ejemplos de creación de adaptadores personalizados en el SDK de BizTalk.

Otra opción es utilizar una página HTTP simple y la respuesta de solicitud HTTP como se explica aquí , toda su lógica se encuentra en la página http. Esto es probablemente más simple si está contento con tener una llamada http y configurar un puerto IIS para escuchar su prueba.

Inicializando pruebas unitarias

Puede importar archivos de enlace en una aplicación BizTalk utilizando un archivo .bat.

Si crea un nuevo archivo de enlace para cada prueba que ejecuta, así como para su configuración de aplicación estándar, puede ejecutar el archivo por lotes apropiado para aplicar el enlace correcto.

Cada archivo de enlace cambiaría su envío de webservice para usar el adaptador personalizado falso y establecer las propiedades específicas para esa prueba.

Incluso podría hacer un paso BizUnit personalizado que (tal vez) genere configuraciones de enlace basadas en configuraciones en el paso de prueba y luego ejecutar los comandos de shell para actualizar los enlaces.

Contenido del mensaje de prueba

Una última cosa que quizás desee considerar, para unir realmente todo esto, es una forma de probar el contenido de los mensajes. Podrías hacer esto en tu adaptador simulado, pero eso sería tedioso muy rápido para mensajes grandes, o para una gran cantidad de posibles mensajes de entrada.

Una opción es crear una canalización personalizada que llame a Schematron para validar los archivos que recibe. Schematron es un lenguaje de esquema que permite un nivel mucho más rico de inspección de archivos que xsd, por lo que puede verificar cosas como "Si el elemento x contiene este contenido, espero que el elemento y esté presente".

Si construyes una interconexión personalizada que toma un esquema schematron como parámetro, entonces puedes intercambiar un archivo de prueba para una prueba de unidad específica, validando que para esta prueba, cuando llamas al servicio web obtienes un archivo que realmente coincide con lo que quieres (y no solo coincide con el xsd)

Esta es una pregunta muy interesante que todavía no he visto una buena respuesta genérica. Algunas personas sugieren usar SoapUI pero todavía no he tenido tiempo de probarlo. Esta página puede ser interesante sobre eso.

Otra forma podría ser ajustar de alguna manera el WebDev.WebHost.dll y usarlo ... Phil Hakkck analiza eso en esta publicación .

También se discutirá antes en SO aquí .

¡Por favor, háganos saber si encuentra otra solución para esto!