Introducción

Instalación

El core el marco está disponible como un típico maven dependency

<dependency>
   <groupId>com.iconsolutions.test</groupId>
   <artifactId>test-fw-core-all</artifactId>
   <version>${latest-version}</version>
</dependency>

test-fw-core-all es un módulo agregador para todos los subcomponentes, pero es completamente posible, y a veces deseable, especificar componentes principales individuales.

Pasos de Gherkin

Lo primero que debe entender al utilizar el marco de pruebas es que escribimos historias BDD utilizando el Gherkin sintaxis para describir el comportamiento de nuestro sistema y probar que actúa como se espera. El lenguaje Gherkin y se mejora aún más procesando toda la entrada a través del Expression Engine, que a su vez da acceso al contexto del escenario actual, todos los mensajes anteriores dentro del escenario, cualquier custom funciones registradas, y bean métodos!

La mayoría de las operaciones de envío, recepción y verificación de mensajes son satisfechas por la biblioteca de pasos en 'CommonTransportSteps', siguen un patrón extremadamente general de:

Enviando un Mensaje

When we send 'Message A' to 'Target System'

When we send 'Message A' to 'Target System' with values:
|Field1 |Value1 |

y luego:

Recibiendo una respuesta

Then a 'Message B' is received

Then a 'Message B' is received with values:
|Field2 |Value2 |

Patrones

Patrones Básicos

El 99% de todas las acciones dentro de una prueba se pueden desglosar en 5 categorías principales, y la mayoría de estas se orquestan a través de la core test-fw aplicación, con la implementación delegada a los implementadores a través de dependency injection y ganchos del ciclo de vida.

Crear- Necesitamos informar al test-fw cómo crear un Mensaje del tipo deseado. Esto se realiza proporcionando una implementación de Generador a la Message Definition
Enviar- Necesitamos informar a la test-fw cómo enviar un mensaje del tipo deseado. Esto se realiza creando y vinculando un Transport de soporte.
Recibir- Es probable que necesitemos poder consumir mensajes de este tipo, típicamente ejemplos de los cuales son al registrarse. JMS Consumidores o encuestando a mock HTTP servidor, y luego añadiendo los mensajes deserializados en el Message Bucket.
Correlacionar- Los mensajes se añaden al Bucket en segundo plano, de manera continua y asíncrona, y a menudo necesitamos poder encontrar nuestro mensaje "pescándolo". Esto se realiza proporcionando un Predicado a uno de los métodos de acceso MessageBucket. Como el 99% del tiempo, el predicado es el mismo para un dado message type, hemos creado el CorrelationStrategy constructo que puede ser proporcionado al Message Definition. Esto permite que el marco extraiga un predicado según sea necesario; para casos negativos / extremos, construir un Predicado manualmente es preferible.
Verifique- Una vez que hemos encontrado un mensaje correlacionado, probablemente deseamos verificar su contenido para comprobar que los valores son correctos. Esto se realiza creando un VerificationService implementación. A bean de este tipo se inyectará automáticamente en los Common Transport Steps y se invocará para CUALQUIER mensaje que se reciba y se correlacione. También es posible registrar una implementación con el Message Definition, que se invocará automáticamente pero solo para el actual. Message Type.

Enviando un Mensaje

Determine/busque un Document Type que puede representar el contenido de su mensaje.
Cree un Message Type para que pueda referirse a ello en BDD.
Asocie el nuevo Message Type con un protocolo Transport adecuado, utilizando la clase de asociación MessageTransport.
Configure y registre un asociado Message Definition (para más información sobre ejemplo message definition s see the test-fw-documentación ipf)

Una vez completado, usted debería poder hacer referencia a su nuevo message type en un paso de BDD. Por ejemplo, el siguiente paso debe ser suficiente para enviar el mensaje al sistema objetivo:

When the 'test system' sends a 'test message'

Lo que sucede tras bambalinas:

El 'mensaje de prueba' se interpreta y se _ apropiado. Message Type_ la instancia es recuperada.
El Message Definition se recupera mediante búsqueda por el Message Type.
El Message Definition proporciona un generador para generar una nueva instancia de Message.
Se identifica un Transport adecuado de la Message Type y tanto Mensaje como Message Definition se pasan al Transport.
El Transporter serializa el Message a un String utilizando el toStringMapper configurado en el Message Definition, y lo envía a través del cable.

El Message Definition

La implementación de cómo construir, enviar, recibir, correlacionar y verificar cada mensaje está completamente definida en el Message Definition, este es un buen ejemplo de Inversion of Control del Test Framework Aplicación. Cualquier nuevo paso que deba ser creado puede ser implementado en cualquier Componente de Spring que extienda BaseSteps, todo beans de este tipo en el classpath se cargan en tiempo de ejecución.

Aprovechamos instancias de @AsParameterConverter para interceptar los argumentos del método proporcionados por cualquier paso dado antes de que lleguen a la implementación Java método. Contamos con un convertidor general para tipos String que permite aplicar transformaciones / análisis en cualquier String a través del Expression Engine. Hay un convertidor para ParamMap que invoca una lógica similar para cada valor y también proporciona un alcance de escenario.caching de los valores evaluados.

Biblioteca de Elementos BDD

A continuación se presentan algunos ejemplos de expresiones que pueden utilizarse comúnmente dentro de un parámetro de cadena para un paso, o como un valor en una tabla de ejemplos.

<aValue> Diamante placeholders-sintaxis estándar de JBehave para utilizar tablas de ejemplos y reutilizar un valor a través de los pasos. Consulte el Tablas de Ejemplos documentación.
#context['TX_ID']-Acceso al contexto, acceso basado en mapas al contexto del escenario
#messageType.aProperty.innerProperty[0]-Acceso a mensajes- acceso basado en propiedades del documento a mensajes previamente manejados (cuando la dirección no está especificada y las instancias de eso message type se han enviado y recibido, se predetermina a lo recibido)
#received_message Type_headers['JMS_CORRELATION_ID']-Acceso al encabezado del mensaje- acceso basado en propiedades a un mensaje recibido previamente JMS ID de correlación
#sent_message Type_meta['QUEUE_NAME']-Acceso a metadatos del mensaje, acceso basado en mapa al nombre de la cola de un mensaje enviado previamente.
@myBean.randomString(35)-La invocación de métodos de Bean, puede evaluar un método en un disponible Spring Bean, útil para la generación de valor
{IS_SET} y {NOT_SET}- Las palabras clave de presencia se manejan y pueden utilizarse para verificar la presencia o ausencia, respectivamente.

Etiquetas de Metadatos de la Historia

También hay varias etiquetas de metadatos comunes que se pueden añadir a nivel de historia o escenario que complementan las pruebas.

@bankContext <val>- We state si el escenario de prueba es desde el punto de vista de un Banco Originante (OB) o de un Beneficiario (BB). Esto se utiliza para ayudar con varios contextos dependientes.behaviours como la mejora de ID y la verificación de cola.
@executionHistory <val>- Podemos proporcionar una ruta a un recurso basado en un archivo que contiene el historial de ejecución en formato BDD para el flujo esperado en cuestión (esto evita tener más de 300 líneas de BDD en cada permutación de escenario probado). Se espera que el valor esperado pertenezca a un archivo con el mismo nombre y una extensión .eh.extension que existe en cualquier lugar del classpath en tiempo de ejecución.
@negativo <true>- Marca esta prueba como una prueba "negativa", lo que elude el paso de aserción implícita dentro del servicio de verificación común, y puede ser utilizado de manera similar para eludir cualquier custom comportamiento que no es apropiado para pruebas negativas o casos límite.
@disableXsdValidation <true>- En la misma línea que el negativo, esto se utiliza para determinar si la prueba debe fallar si se viola alguna validación basada en el esquema de Object-String configurado. Esto casi siempre se omite, pero puede ser útil para probar el envío de un mensaje estructuralmente inválido.
@enprogreso (*)- Demuestra que la prueba está en desarrollo y está igualmente incluida en el ejecutor de pruebas estándar que se ejecuta como parte de una compilación. Muchos proyectos también cuentan con un ejecutor de pruebas específico en progreso que ejecutará SOLAMENTE estas pruebas.
@unparallelisable (*)- Todos los tests se ejecutarán de manera concurrente por defecto. En la remota posibilidad de que esto no sea posible debido a la prueba de un recurso compartido, podemos flag la prueba debe ejecutarse en un conjunto separado, de manera secuencial.

*Estas etiquetas rigen el TestRunners solo, no el contexto del escenario, por lo tanto, solo se necesita su presencia sin ningún valor explícito.