A continuación, mezclar y cuando está en TDC Historias de usuario / pruebas de aceptación

Question

¿Cómo se manejan las historias de usuario pruebas / aceptación que tienen cadenas largas como ésta, donde el Entonces / Cuando se mezclan juntos? Es la mejor forma de dividir esto en una prueba de aceptación separado donde se prueba que los Aparece el diálogo y luego la segunda prueba el comportamiento después de que el diálogo se ha demostrado?

Feature: Confirmation before removing products from cart
  In order to avoid accidentally removing an item from my cart
  As a Customer
  I want a confirmation dialog to ask me if I'm sure I want to remove an item

  Scenario: I want to remove an item from my cart
    Given I have added item "xyz" to my cart
    When I click "Remove"
    Then a confirmation dialog pops up
    And it asks "Are you sure you want to remove this from your cart"
    When I click "Yes"
    Then item "xyz" should be removed from my cart

Answer 1

Su escenario parece un poco largo, y está muy fuertemente ligada a la interfaz gráfica de usuario. ¿Qué pasaría si se ató a las capacidades del sistema en lugar?

Scenario: I want to remove an item from my cart
  Given I have a cart containing "xyz"
  When I remove "xyz" from my cart
  Then my cart should be empty.

El escenario ahora describe cosas que son útiles para el usuario, y es más fácil de refactorizar.

Me encanta BDD tanto como lo hago porque tenía una situación muy parecida a esta. Tuvimos 120 pruebas de aceptación y eran en su mayoría fallando. Alguien había puesto un cuadro de diálogo de confirmación en muy parecida a la que usted describe, y al instante se rompió más de 80 pruebas de aceptación. Al convertirlos en escenarios de alto nivel, pasos reutilizables en lugar, podemos refactorizar fácilmente y mantener las pruebas de trabajo, incluso si los mecanismos que utilizamos para poner en práctica las capacidades del sistema cambian. El chasquido real de botones que ocurre dentro de esos pasos reutilizables, y que está bien tener más de una acción de interfaz de usuario por paso.

Me escribió un escenario que hace esto aquí si es útil (es un DSL en lugar de Inglés, pero usted debe tener una idea):

http://code.google .com / p / wipflash / fuente / Navegar / Example.PetShop.Scenarios / PetRegistrationAndPurchase.cs

Answer 2

La cuestión es realmente uno de lo que las "ramas" son.

Si hay varios pasos que debe ser elecciones de los usuarios en cada paso. No debe haber múltiples "Cuando" 's. Esto debe formar un árbol rico con una gran cantidad de alternativas seleccionadas por el usuario en cada rama. Cada resultado posible debe tener su propia prueba para hacer que las diferentes opciones y llegar a ese resultado.

Una secuencia de tres pasos con dos opciones de usuario es de 8 caminos posibles. Diferentes caminos pueden llegar al mismo resultado (o no). Sin embargo, usted debe tener varias rutas a través de este.

Si es sólo secuencial (porque alguien se sentía como escribir pasos secuenciales) y el usuario no tiene opciones, entonces en realidad no es impulsado por la consideración de la conducta del usuario, ¿verdad?

no veo las opciones. No había opciones == mal olor. Pero fácil de prueba, ya que sólo hay un resultado con una secuencia de pasos en cautiverio en el que el usuario tiene pocos o ningún opciones.

Si usted se resuelve adecuadamente las opciones, a continuación, cada paso tiene múltiples resultados y cada paso debe ser probada de forma independiente.