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

Durante el uso de Karate, pudimos hacer la mayoría de las validaciones para servicios web, pudimos integrar Karate con Selenium webdriver y hacer afirmaciones DB utilizando clases de Java. Para DB devolvimos los conjuntos de resultados como lista convirtiendo cada fila como hashmap y Karate la tomó como json array. Entonces las validaciones se hicieron simples. La mayoría de las necesidades de QA se han logrado utilizando Karate.

Sin embargo, hoy, cuando lo presentamos, a una comunidad más grande, uno de los líderes del desarrollo se le ocurrió una pregunta. Es un experto en JBehave, BDD, jsonpath, java, servicios web, etc. También consideramos que su pregunta es realmente relevante en función de nuestro contexto. sin embargo, el enfoque de Karate es diferente y puede no funcionar de acuerdo a nuestro conocimiento.

En nuestro contexto, tenemos que hacer que el BA escriba el BDD teniendo en cuenta sus escenarios comerciales utilizando términos comerciales y QA / Dev puede convertirlos posteriormente como scripts. (Un enfoque que generalmente seguimos usando pepino + selenium / tenga la seguridad, etc.). Por ejemplo, si tengo un archivo de características y 10 escenarios , las personas del lado de la empresa no entenderán los detalles de las validaciones al ver los pasos en karate / o en otra palabra, el texto en inglés simple será un poco más fácil de explicar para ellos. Necesitamos este enfoque porque tratamos de 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 detallada del blog aquí: Sí, Karate no es cierto BDD

Léalo detenidamente y compártalo con aquellos que se beneficiarán. Sí, Karate roba la syntax BDD de Cucumber, pero luego toma una dirección diferente.

Puede utilizar Karate detrás de las escenas como definiciones paso a paso de Cucumber a través de la API de Java . O si desea utilizar algo como REST-asegurado, potencia total para usted .

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

  • Asegurarse de que el pepinillo “BA friendly” sea verdaderamente “inglés llano” y esté en el nivel correcto de abstracción (dependiendo de a quién le preguntes). Prepárese para debates interminables sobre si sus escenarios de Cucumber contienen detalles de “implementación específica” o no.
  • En realidad, consigue que tus BA-s escriban el pepinillo o al menos colaboren con el equipo de desarrollo para escribirlos. Por cierto, es esta colaboración la que tiene el mayor valor que obtienes de BDD, no la automatización de las especificaciones como pruebas ejecutables. Entonces, si realmente puedes hacer esto (obtener tiempo y experiencia en Gherkin de tus BA-s), ¡enhorabuena! No muchos equipos pueden lograr esto.
  • Por supuesto, Gherkin es solo la punta del iceberg, necesitas ir y escribir todas las definiciones de paso. 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 tal vez negativo) valor para las pruebas API. La gran diferencia entre una prueba de UI (cara humana) frente a una prueba de API (cara de máquina) es que hay un claro “contrato” que 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 te obliga. ¡El usuario final o consumidor de una API es típicamente otro progtwigdor ! Sí, hay una necesidad de pensar en la API como un producto , pero BDD simplemente está llevando las cosas demasiado lejos. Y especialmente cuando se trata de micro-servicios, rara vez encontrará uno que esté haciendo algo más complejo que el simple ‘CRUD’.
  • Hágase esta pregunta: ¿espera que sus licenciados sigan leyendo el pepinillo después de la fase de definición de requisitos del proyecto? Tenga en cuenta que BDD se supone que debe practicarse antes de escribir una sola línea de código . Si Gherkin ha cumplido su propósito de establecer colaboración, una comprensión compartida y ejemplos, ¡simplemente conviértalo en pruebas automáticas normales y no mire hacia atrás!

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

Espero que ayude 🙂

    Intereting Posts