cucumber - En Karate, cómo podemos trabajar en colaboración con BA para automatizar escenarios de negocios

bdd cucumber-jvm (1)

Si bien utilizamos Karate pudimos hacer la mayoría de las validaciones para los servicios web, pudimos integrar Karate con éxito con el controlador web Selenium y hacer aserciones de DB utilizando clases java. Para DB, devolvimos los conjuntos de resultados como una lista al convertir cada fila como un hashmap y Karate lo tomó como una matriz json. Entonces las validaciones se volvieron simples. La mayoría de las necesidades para nosotros en el lado del control de calidad se han logrado utilizando Karate.

Sin embargo, hoy, cuando lo presentamos a una comunidad más grande, uno de los líderes de desarrollo hizo una pregunta. Es un experto en JBehave, BDD, jsonpath, java, servicios web, etc. También sentimos que su pregunta es realmente relevante según nuestro contexto. Sin embargo, el enfoque del Karate es diferente y puede que no funcione de acuerdo con nuestro conocimiento.

En nuestro contexto, tenemos que hacer que el BA escriba el BDD considerando sus escenarios comerciales utilizando términos comerciales y QA / Dev puede convertirlos posteriormente como scripts. (Un enfoque que usualmente usamos usando pepino + selenio / tenga la seguridad, etc.). Por ejemplo, si tengo un archivo de características y 10 escenarios en eso, las personas del lado comercial no entenderán los detalles de las validaciones al ver los pasos en karate / o en otra palabra, el texto en inglés será un poco más claro para ellos. Necesitamos este enfoque porque intentamos implementar cambios en el proceso desde el nivel de la historia en sí.

¿Podrías compartir tus pensamientos?

Respuesta corta: Karate no es para BDD.

Escribí una publicación de blog detallada al respecto aquí: Sí, Karate no es cierto BDD

Léalo detenidamente y compártalo con quienes se beneficiarán. Sí, Karate le roba la sintaxis BDD a Cucumber, pero luego toma una dirección diferente.

Es posible que pueda usar Karate detrás de escena como definiciones de pasos de Cucumber a través de la API de Java . O si desea utilizar algo como REST -EDED, potencia total para usted .

Mi opinión personal es, por favor no. Estarás perdiendo el tiempo haciendo esto:

Asegurarse de que el "Gherkin amistoso con BA" es verdaderamente "inglés simple" y está en el nivel correcto de abstracción (dependiendo de a quién le pregunte). Prepárese para debates endless debates si sus escenarios de Cucumber contienen detalles "específicos de la implementación" o no.
Realmente haciendo que tus BA-s escriban el Gherkin o al menos colaboren con el equipo de desarrollo para escribirlos. Por cierto, esta colaboración es el mayor valor que obtienes de BDD, no la automatización de la especificación como pruebas ejecutables. Entonces, si realmente puede hacer esto (obtener tiempo y experiencia de Gherkin de sus BA-s), ¡felicidades! No muchos equipos son capaces de lograr esto .
Por supuesto, Gherkin es solo la punta del iceberg, debes ir y escribir todas las definiciones de pasos. Habría visto esta parte de la documentación de Karate que describe las diferencias entre Karate y Pepino .
Tengo un fuerte punto de vista de que BDD tiene muy poco (y quizás negativo) valor para las pruebas API. La gran diferencia entre una prueba de IU (cara humana) frente a una prueba API (cara de máquina) es que hay un "contrato" claro al que se está codificando. Este contrato se expresa mejor en términos técnicos (JSON / esquema) en lugar de la abstracción deliberada en la que BDD lo obliga. ¡El usuario final o consumidor de una API es típicamente otro programador ! Sí, es necesario pensar en la API como un producto , pero BDD simplemente está llevando las cosas demasiado lejos. Y especialmente cuando se trata de microservicios, rara vez se encontrará con uno que esté haciendo algo más complejo que el simple ''CRUD''.
Hágase esta pregunta: ¿espera que sus BA-s continúen leyendo el Gherkin después de la fase de definición de requisitos del proyecto? Tenga en cuenta que se supone que BDD se practica antes de escribir una sola línea de código . Si el Gherkin ha cumplido su propósito de establecer una colaboración, una comprensión compartida y ejemplos, ¡simplemente conviértalo a pruebas automatizadas normales y no mire hacia atrás!

EDITAR: Mira el segundo ejemplo aquí para ver qué sucede cuando usas Cucumber para probar lo que debería ser una unidad simple o una prueba de integración.

Espero que ayude :)