Uso de SpecFlow para pruebas de regresión de extremo a extremo

Question

Estamos utilizando BDD y utilizando SpecFlow para impulsar nuestro desarrollo (ATDD).

Nuestro equipo de control de calidad quisiera definir sus propias pruebas de regresión de extremo a extremo (en Gherkin/SpecFlow) y reutilizar los Pasos que ya hemos definido.

(Tenga en cuenta - Sé que esto no es un gran ejemplo, pero debe proporcionar suficientes detalles)

Una prueba puede incluir ..

1. Acceder
2. Buscar un producto
3. seleccionar un producto para comprar
4. crear un orden Seleccionar la opción de entrega
5. .
6. Envíe la orden.
7. Cancele el pedido.

Esto haría sugiere un escenario como ..

Dada estoy conectado
cuando la búsqueda de un producto
Y seleccionar un producto para comprar
Y crear un orden
Y I Seleccione la opción de entrega
y envío el pedido
y cancelo el pedido
Entonces ?? !!

Lo cual es claramente incorrecto ya que no estamos verificando la salida en cada paso.

Así que este puede resolverse como una secuencia de escenarios:

Escenario 1:
Dado estoy conectado
cuando la búsqueda de un producto
entonces veo una lista de productos

Escenario 2:
Cuando selecciono un producto para comprar
Entonces puede crear una orden

Escenario 3:
Cuando creo el orden
Y seleccione la opción de entrega
Entonces puedo enviar la orden

, etc, etc

El principal problema con esto es que parece que no hay manera para especificar el orden/secuencia en que se ejecutan los escenarios (una característica de nUnit?). Debido a que existen dependencias entre los escenarios (no se establecen en un punto de inicio conocido), deben ejecutarse en secuencia.

Mis preguntas son:

a) estamos tratando de encajar una clavija cuadrada en un agujero redondo ?!

b) ¿Alguien sabe si hay alguna manera de usar SpecFlow/Gherkin de esta manera?

c) ¿Alguien sabe qué alternativas hay?

¡Muchas gracias!

Answer 1

Diría que está escribiendo sus escenarios en el nivel de abstracción incorrecto. Pero eso depende de para qué los quiera usar;

Si quiere escribir scripts de prueba, entonces está en el camino correcto ... pero será una pesadilla mantenerlo, en el primer caso (secuencia de comandos larga) será muy frágil y el segundo caso (varios escenarios) necesitan asegurar un cierto orden de ejecución. Ambos están desalentados y considerados antipatrones.

Le sugiero que combine las pruebas ATDD que está escribiendo y hable con el departamento de pruebas para obtener su opinión sobre el asunto e incluir los casos de prueba que necesitan para garantizar que el sistema sea probado minuciosamente. ¿Quien sabe? Incluso podría aprender algo el uno del otro: P

Y cuando escribe esas "especificaciones" (como prefiero llamarlas) las escribe en un nivel superior. Así que en lugar de escribir:

Given I am logged in 
When I Search for a product 
    And I Select a product to buy 
    And I Create an order 
    And I Select delivery option 
    And I Submit the order 

se escribe algo así como

When I submit an order for product 'Canned beans' 

en la etapa de definiciones detrás de ese paso de llevar a cabo todo lo que la automatización (inicio de sesión, navegar a la página del producto, seleccione las opciones de entrega, enviar el pedido).

Todo esto se puede leer acerca de estos grandes artículos sobre cómo escribir pruebas mantenibles de UI Automation:

• http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
• http://elabs.se/blog/15-you-re-cuking-it-wrong
• http://www.marcusoft.net/2011/04/clean-up-your-stepsuse-page-objects-in.html
• http://dhemery.com/pdf/writing_maintainable_automated_acceptance_tests.pdf
• http://gojko.net/2010/01/05/bdd-in-net-with-cucumber-part-3-scenario-outlines-and-tabular-templates/
• http://chrismdp.github.com/2011/09/layers-of-abstraction-writing-great-cucumber-code/
• http://benmabey.com/2008/05/19/imperative-vs-declarative-scenarios-in-user-stories.html
• http://mislav.uniqpath.com/2010/09/cuking-it-right/

espero que esto ayude a