En este caso voy a describir la funcionalidad que tiene la herramienta para crear objetos mocks que simulen un servicio Web, en la documentación del SoapUI los denominan MockService.
Los objetos Mock son objetos que permite simular los servicios externos al código que queremos probar.
Por ejemplos si estamos probando una componente de acceso a datos necesitaríamos tener acceso a la base de datos, que esta contenga datos de prueba válidos etc, por lo tanto dependeríamos del estado de la base de datos, la conectividad a ella y tener los permisos necesarios. Una alternativa sería simular el comportamiento de la base de datos utilizando objetos simulados que tenga el comportamiento esperado para el sistema real antes determinado conjunto de datos de entrada.
Luego de esta breve introducción vamos a ver como implementar MockServices usando el SoapUI
Lo primero que debemos hacer es generar un proyecto SoapUI en base al WSDL del servicio que queremos simular. Le asignamos el nombre TestCreditRiskService y habilitamos las opciones “Create Test Suite” y “Create Mock Service” dejando los otros valores por defecto sin alterar.
En la ventana “Generate Test Suite” dejar las opciones por defecto.
Para hacer una prueba manual del servicio se utilizan los mensaje xml de entrada creado por la herramienta, por defecto se crea uno, pero se pueden crear todos los necesarios con le menú contextual sobre el nombre del servicio.
En este ejemplo el servicio original está corriendo en la máquina local y los datos válidos de prueba son dni=12345678 y dni=23456789, de lo cuales obtenemos reportes de riesgo crediticio diferentes.
Para agregar un objeto Mock para un servicio Web (MockServices) se puede utilizar el creado cuando
se generó el proyecto o bien con el menú contextual sobre la interfase.
Este MockServices implementa el patrón de Service Stub para acceder a la simulación el servicio web original o bien al servicio original, esto se camb
ia seleccionando el endpoint correspondiente.
Para el MockServices creado asignamos un Response simulado en base al Request2
Los endpoint asignados a los mockservices se puede ver directamente invocando en el navegador la url asignada al MockService.
Por lo tanto si vamos a nuestro request original podríamos ejecutar el mismo pero invocando al MockService creado.
Agregamos el endpoint de la interfase RiskClientServiceSoap para que use como interfase de entrada.
El MockService ya está corriendo, el último paso de configuración es redireccionar nuestra interfase del servicio original al servicio simulado.
Conclusión:
Utilizando el SoapUI se pueden hacer pruebas unitarias de servicios web en un forma muy simple, además permite hacer pruebas de carga.
Con los MockService podemos además empezar a dsarrollar el código que lo invoca antes de que la implementación real del servicio esté disponible.
Obviamente que está situación es útil cuando el contrado ya está bien definido y la implementación real tenga los menores cambios para que no impacte lo que ya se hizo.
4 comentarios:
Hola Sergio,
He leído tus tres artículos sobre la metodología TDD y me han parecido realmente interesantes.
En estos momentos yo estoy tratando de implantar el TDD en mi empresa. Pero al tratar de adaptarla me están surgiendo una serie de dudas que seguro tu ya las habrás resuelto cuando empezaste a usar esta metodología.
Te explico cuál sería nuestro ciclo de desarrollo de un proyecto software:
El primer paso sería determinar las pruebas de aceptación a partir de los requisitos definidos. ¿En este punto se empezarían ya a codificar estas pruebas de aceptación o esperamos a tener el siguiente paso realizado que se explica a continuación? Esta es mi primera duda.
El segundo paso que hacemos es desglosar cada requisito en tareas. Actualmente sobre cada una de estas tareas se escribe el código necesario y realizamos pruebas. Si ahora queremos aplicar la metodología TDD, primero definiremos las pruebas unitarias, luego con cada prueba se codificará y se realizará el código para que sea correcta la prueba.
Mi principal duda es en qué orden se realizarían los dos pasos anteriores y cuál es el proceso que deberíamos seguir para pasar de tener las pruebas de aceptación definidas a comprobar que son correctas.
A nivel de documentación, ¿sería interesante tener registro de todo tipo de pruebas?, ¿cómo y cuáles crees tu que sería mejor documentarlas o no merece la pena guardar registro de ninguna de las pruebas?.
Por otro lado podrías recomendarme alguna herramienta de software libre para análisis de cobertura de código en la ejecución de pruebas (Java, AS400, VB). ¿Cuál crees tu que sería el porcentaje de cobertura ideal?
Espero que me aclares un poco todas estas ideas que te planteo.
Muchas gracias por todo, me eres de gran ayuda.
Un abrazo
Hola Aris:
Lo primer en TDD en convencer a los lideres de proyecto que implica un cambio en la metodología de diseño y desarrollo del software que se está por construir. Eso implica considerar en los planes el tiempo que se va a dedicar a construir las pruebas unitarias automáticas, esta es una parte dificil pues al principio no se ven los beneficios.
Por eso hay que enfocar el tema en los beneficios futuros, que son:
- Mayor calidad del código generado porque se tiene mucho más cobertura del código probado (si se aplica bien la metodología sería del 100%).
- Mejor respuesta a los cambios pues las pruebas de regresión implica solamente ejecutar las pruebas automatizadas nuevamente para ver si los cambios aplicados impactaron donde se neceitaba y no "rompió" otra parte del proyecto.
- Si a esto se agrega la utilización de metodologías agiles como Scrum e integración continua se puede tener código ejecutable para mostrar a los usuarios en relativamente poco tiempo. Todo depende del tamaño del proyecto y del tiempo entre iteraciones/release (en Scrum son como máximo cada mes).
A nivel pruebas de aceptación no tengo experiencia, en el grupo de AltNet hispano están planificando presentaar una presentación virtual (VAN) sobre ese tema en esta semana.
Herramientas hay y muchas, si estás trabajando con .Net el Team Foudation Server TFS integra desarrollo , pruebas, implementación, cobertura y control de calidad de código, generación de metricas en cubos, administración de recursos, de control de código etc en forma nativa, pero también se pueden agregar más funcionalidad usando MSBuild y Power Shell Script, como por ejemplo definir el grado de cobertura aceptable para poder implementar etc.
A nivel open source podria sugerir según que parte del proceso desean automatizar, pues son herramientas individuales.
NUnit para pruebas unitarias
automáticas. Para la parte web podrías usar Selnium (lo van a explicar en la VAn mencionada).
Nant para generar script para automatizar (por ejemplo una vez hice uno que ejecuta las prubas unitarias y generar un html con lso resultados).
Hudson para integración continua (se basa en java pero aplica a .net mediante plugins).
Subversion SVN para control de fuentes, Hudson se integra con SVN para que lso desarrolladores suban al servidor de integración y este se encarga de ejecutar la compilación, pruebas y genera los reportes.Este último escenario aún no tuve tiempo de implementar, pero por lo que investigué tiene buena aceptación.
Espero que esta información te haya sido de utilidad.
Saludos
Muy buenas Sergio,
Te agradezco muchísimo tu información y consejos, la verdad es que me van a ayudar bastante para empezar a implantar esta metodología en mi empresa.
Ya te iré contando cómo va llendo la todo.
Cuídate,
Un saludo
Aris
Muy buenas Sergio,
Te agradezco muchísimo toda tu información y consejos, la verdad es que me van a ayudar muchísimo para empezar a implantar la metodología en mi empresa.
Ya te iré contando como va todo.
Cuídate mucho.
Un saludo,
Aris
Publicar un comentario