¿Deben los escenarios BDD incluir datos de prueba reales o simplemente describirlos?

Question

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

Opción 1: describir los datos a utilizar, y dejar que la aplicación define el 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: explícitamente indican 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 bene ajustes y desventajas, lo que hemos establecido es que:

La opción 1 cubre muy bien el caso cuando cambia la definición de decir un "nombre válido". Esto podría ser más difícil de tratar si optamos 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 fuera un escenario en el que dijéramos 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, estando más preocupado con la descripción que con 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 sea utilizada por este escenario. Por el contrario, podríamos implementar la opción 2 "la página debe mostrar los siguientes campos" de forma que pueda ser reutilizada muchas veces por otros escenarios.

También creo que la opción 2 parece más amigable 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". ¿Sería la Opción 2 más frágil? Refactorizar el modelo puede significar romper estas pruebas, mientras que si los datos de prueba están definidos en código, el compilador nos ayudará con los cambios del modelo.

Agradezco 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

Yo diría que depende. Hay momentos 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 son importantes para lo que realmente estamos probando y, por lo tanto, se convierten en un ruido que distrae del entendimiento que estamos tratando de lograr con el Escenario.Empecé a usar algo que llamo un patrón de datos predeterminados para proporcionar datos predeterminados que se pueden fusionar con datos específicos del escenario. He escrito sobre él aquí:

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

espero que esto ayude.

Answer 2

prefiero la opción 2.

Para el usuario de negocios es inmediatamente claro qué 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.

Puede ser aún más expresiva mediante la adición de datos no válidos también, 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 | 

Usted debe sin embargo mantener los datos por lo que su descrita en términos de dominio, en lugar de que la aplicación específica. Esto le permitirá probar en diferentes capas en su aplicación. p.ej. Servicio de interfaz de usuario, etc.

Answer 3

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