Documentation for a newer release is available. View Latest

TEST1 - Añadir tests

Comenzando

Este paso del tutorial utiliza como punto de partida la solución add_http del proyecto.

Si en cualquier momento quieres ver la solución de este paso, la encontrarás en la solución add_tests.

Hasta ahora nos hemos centrado en implementar distintas capacidades del Framework IPF y ver cómo combinarlas para arrancar rápidamente una aplicación IPF. Sin embargo, aún no hemos explorado cómo probar nuestra aplicación.

En esta etapa presentaremos el Framework de Tests de Icon y mostraremos cómo puede usarse para probar la aplicación que has construido. Supondremos que tienes nociones básicas de Icon Test Framework, y entendimiento de BDD y de la sintaxis Gherkin.

El Framework de Tests de Icon

Conceptos

Resumimos algunos conceptos clave:

  • Message: abstracción para cualquier "mensaje" gestionado por la implementación del framework (request, response, payload, etc.). Un mensaje se tipa contra un tipo Java conocido que representa la forma deserializada (Document Type).

  • MessageType: representación del tipo de mensaje referenciable desde el BDD; debería existir correspondencia 1:1 con el Document Type del mensaje.

  • MessageDefinition: estructura contextual que proporciona funcionalidad para manejar mensajes del tipo configurado (punto de inversión de control con el framework). Suele haber mapeo 1:1 con MessageType.

  • MessageBucket: colección encapsulada donde se acumulan mensajes recibidos por el Test Framework; se accede con predicados para "pescar" el mensaje correlacionado.

  • Transporter: abstracción del protocolo (HTTP, JMS, Kafka…​)

  • Context: contexto por escenario con info de test (thread-local; se limpia entre escenarios por hooks de JBehave).

No te preocupes si parecen abstractos: quedará más claro en el resto del tutorial.

Extensiones

Usaremos la extensión ipf-test-fw-whitebox para facilitar la escritura de tests de apps IPF:

<dependency>
    <groupId>com.iconsolutions.ipf.core.test</groupId>
    <artifactId>ipf-test-fw-whitebox</artifactId>
    <scope>test</scope>
</dependency>

Aporta:

1) Pasos preconstruidos que aprovechan: a) estructura de system events de IPF b) operaciones de modelo para interrogar el aggregate de un flujo 2) Pasos comunes (inicio/fin de escenario) 3) Transporters utilitarios para stubs HTTP, Kafka y JMS

Configuración del proyecto de tests

Crearemos un módulo Maven ipf-tutorial-application-tests para alojar tests BDD y recursos, con estructura típica src/test/resources/stories.

Primer test BDD

Crearemos una historia HappyPath.story con pasos Given/When/Then básicos: salud del servicio, enviar initiation request, comprobar inicio de flujo y recepción de initiation response.

Implementación del test (Parte 1)

  • Runner SpringBootTest extendiendo IPFFeatureTestRunner (+ AllTestConfig), con contenedores de prueba para Mongo y Kafka, y tópicos necesarios.

  • Config de iniciación: MessageTypes y MessageDefinitions para initiation request/response, y transporte HttpSenderTestTransporter. Propiedad application.base.url en application.conf.

  • Dependencias adicionales: junit-vintage-engine y wiremock-standalone para simular el endpoint de ODS.

Ejecutar el test

Ejecuta el runner desde IDE o vía Maven (failsafe plugin; incluye **/*Runner.java).

Añadir la ejecución del pago

Ampliamos el escenario con pasos para: arranque del flujo de ejecución, llamada a sanciones (Kafka), respuesta de sanciones, llamada a fraude (HTTP), respuesta de fraude, y verificación de estado Complete para IpftutorialflowV2 e InitiationFlow.

Implementación del test (Parte 2)

  • SanctionsConfig: MessageTypes (request/response), MessageDefinitions (Kafka: fromStringMapper y generator), KafkaTestTransporter con propertiesPath "sanctions".

  • FraudConfig: MessageTypes (request/response), generator que rellena OlafResponse, HttpConsumerTestTransporter con puerto configurable (fraud.http.client.port).

Asserts de valores

Ejemplo:

And Sanctions receives a 'sanctions request' with values:
| payload.filteringRequest.amount.currency | US |

Ejecución en Maven

Añade maven-failsafe-plugin para fases integration-test y verify, incluyendo el patrón **/*Runner.java y excluyendo tests unitarios por convención.

Ejercicio

Extiende la historia para cubrir etapas no-op omitidas: duplicate check passed, account validation passed, clear and settle passed, usando el paso "a {event name} event is raised".

Conclusiones

Hemos configurado y ejecutado un test BDD de integración usando el Framework de Tests de Icon, incluyendo sanidad, orquestación de mensajes con transporters y validación de estados del flujo.