Introducción
Instalación
El marco central está disponible como una dependencia típica de maven.
<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 es 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:
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 del núcleo.test-fw aplicación, con la implementación delegada a los implementadores a través de la inyección de dependencias y los ganchos del ciclo de vida.
-
Crear- Necesitamos informar a la 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 al 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 un simulacro 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, por lo que 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 tipo de mensaje dado, 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 manualmente un Predicado 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 la Message Definition, que se invocará automáticamente pero solo para el actual. Message Type.
Enviando un Mensaje
-
Determine/encontrar 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 las definiciones de mensajes de ejemplo, consulte el test-fw-ipf documentación)
Una vez completado, usted debería poder referenciar su nuevo tipo de mensaje en un paso de BDD. Por ejemplo, el siguiente paso debería ser suficiente para enviar el mensaje al sistema objetivo:
When the 'test system' sends a 'test message'Lo que sucede tras bambalinas:
-
'mensaje de prueba' se interpreta y el _ 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.
-
Un Transporte adecuado es identificado a partir del 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 almacenamiento en caché de los valores evaluados con un alcance específico del escenario.
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 de documentos a mensajes previamente manejados (cuando la dirección no está especificada y se han enviado y recibido instancias de ese tipo de mensaje, se predetermina a lo recibido)
-
#mensaje_recibido Tipo_encabezados['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 meta-datos comunes que se pueden añadir a nivel de historia o escenario que complementan las pruebas.
-
@bankContext <val>- Declaramos 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 comportamientos dependientes del contexto, como la mejora de ID y la verificación de colas.
-
@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 que exista en cualquier lugar del classpath en tiempo de ejecución.
-
@negativo <verdadero>- 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 cadena de objeto configurado. Esto casi siempre se omite, pero puede ser útil para probar el envío de un mensaje estructuralmente inválido.
-
@inProgress (*)- 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 (*)- Todas las pruebas 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 marcar la prueba para que se ejecute 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.