cucumber - sintaxis - ¿Deben los escenarios BDD incluir datos de prueba reales, o simplemente describirlos?

que es bdd

Question

Hemos llegado a un punto en el que nos hemos dado cuenta de que hay dos opciones para especificar datos de prueba al definir un escenario de CRUD típico:

Opción 1: Describa los datos a utilizar y deje que la implementación defina los datos.

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have typed in a valid name
      And I have typed in a valid code
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the created region details

Opción 2: indicar explícitamente los datos de prueba a utilizar

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have filled out the form as follows
        | Label | Value  |
        | Name  | Europe |
        | Code  | EUR    |
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the following fields
        | Name   | Code |
        | Europe | EUR  |

En términos de beneficios e inconvenientes, lo que hemos establecido es que:

La opción 1 cubre muy bien el caso cuando cambia la definición de "un nombre válido". Esto podría ser más difícil de manejar si optáramos por la Opción 2 donde los datos de prueba se encuentran en varios lugares. La opción 1 describe explícitamente lo que es importante acerca de los datos para esta prueba, especialmente si se tratara de un escenario en el que decíamos algo como "ha escrito un número de tarjeta de crédito no válido". También "se siente" más abstracto y BDD de alguna manera, está más preocupado por la descripción que por la implementación.

Sin embargo, la Opción 1 utiliza pasos muy específicos que serían difíciles de reutilizar. Por ejemplo, "la página debe mostrar los detalles de la región creada" probablemente solo será utilizada por este escenario. A la inversa, podríamos implementar la Opción 2 "la página debería mostrar los siguientes campos" de manera que otras situaciones la puedan reutilizar.

También creo que la Opción 2 parece ser más fácil para el cliente, ya que pueden ver con el ejemplo lo que está sucediendo en lugar de tener que interpretar términos más abstractos como "válido". ¿La opción 2 sería más frágil? Refactorizar el modelo podría significar romper estas pruebas, mientras que si los datos de la prueba se definen en el código, el compilador nos ayudará con los cambios del modelo.

Aprecio que no haya una respuesta correcta o incorrecta aquí, pero me gustaría escuchar las opiniones de las personas sobre cómo decidirían cuál usar.

¡Gracias!

Answer 1

Cada vez que pienso en esto, cambio de opinión. Pero si lo piensas bien, la prueba es para demostrar que puedes crear una región. A Criterios cumplidos por ambas opciones. Pero estoy de acuerdo en que las señales visuales con la opción 2 y la amabilidad del desarrollador son probablemente demasiado buenas para rechazarlas. En ejemplos como este, al menos.

Answer 2

Prefiero la opción 2.

Para el usuario de negocios, queda inmediatamente claro cuáles son las entradas y las salidas. Con la opción 1 no sabemos qué datos son válidos, por lo que su implementación puede ser incorrecta.

También puede ser más expresivo al agregar datos no válidos, cuando sea apropiado

Scenario: Filter for Awesome
    Given I have navigated to the "Show People" page
    And I have the following data
    | Name  | Value  |
    |  John | Awesome|
    |  Bob  | OK     |
    |  Jane | Fail   |
When I click the "Filter" button
Then the list should display    
    | Name   | Value   |
    |  John  | Awesome |

Sin embargo, debe mantener los datos para que se describan en términos del dominio, en lugar de la implementación específica. Esto le permitirá probar en diferentes capas en su aplicación. por ejemplo, servicio de interfaz de usuario, etc.

Answer 3

Yo diría que depende. Hay ocasiones en que un escenario puede requerir una gran cantidad de datos para completar una ejecución exitosa. A menudo, la mayoría de esos datos no es importante para lo que realmente estamos probando y, por lo tanto, se convierte en una distracción del ruido de la comprensión que estamos tratando de lograr con el Escenario. Comencé a usar algo que llamo un patrón de datos predeterminado para proporcionar datos predeterminados que pueden combinarse con datos específicos del escenario. He escrito sobre esto aquí:

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

Espero que esto ayude.