2011-03-30 14 views
9

Somos nuevos en bdd/pepino y discutimos en nuestro equipo cómo escribir las características/escenarios correctos.mejor práctica para escribir funciones/escenarios de pepino bdd real

nos ocurrió con los dos enfoques siguientes, que casi se deben describir/resolver el mismo requisito:

Feature: Give access to dossiers to other registered users 
    As a logged in user 
    In order to show my dossier to other users 
    I want to give other users (limited) access to my dossiers 

    Background: 
    Given I am logged in as "Oliver" 
    And another user "Pascal" exists 
    And another user "Tobias" exists 

    Scenario: I can give access to my own dossier 
    When I grant access to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Oliver" 

    Scenario: I can give access to a created dossier 
    Given I created a new dossier "Max Müller" 
    When I grant access on dossier "Max Müller" to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Max Müller" 

    Scenario: I can give access to a managed dossier 
    Given I manage the dossier from "Tobias" 
    When I grant access on dossier "Tobias" to "Pascal" with permisson "readonly" 
    Then I should see "Access granted." 
    And user "Pascal" should have permission "readonly" on dossier "Tobias" 

    Scenario: I cannot give access to a writable dossier 
    Given I have write access to the dossier from "Tobias" 
    When I follow "Grant access" 
    Then I should see "You are not allowed to grant access on this dossier." 

    Scenario: I cannot give access to a readonly dossier 
    Given I have readonly access to the dossier from "Tobias" 
    When I follow "Grant access" 
    Then I should see "You are not allowed to grant access on this dossier." 

    Scenario: I can give access to a dossier with an expiration date 
    Given I created a new dossier "Max Müller" 
    When I grant access on dossier "Max Müller" to "Pascal" with permisson "readonly" until "2020-01-01" 
    Then I should see "Access granted till 2020-01-01." 
    And user "Pascal" should have permission "readonly" on dossier "Max Müller" until "2020-01-01" 

    Scenario: I cannot transfer a created dossier to a new owner who is already registered 
    Given I created a new dossier "Max Müller" 
    When I transfer dossier "Max Müller" to "Pascal" 
    Then I should see "Pascal already has a dossier, transfer not possible." 

La segunda:

Feature: Grant access on dossiers to registered users 
    As a logged in user 
    In order to allow others to view/ manage dossiers I have access to 
    I want to give access of those to other users 

    Background: 
    Given I am logged in as "[email protected]" 
    And I am working with my own dossier 

    Scenario: Invalid data entered 
    When I visit the grant dossier access page 
    And I press "Grant access" 
    Then I should see a validation error on "eMail-Address" 

    Scenario: Valid data entered 
    Given a user "[email protected]" exists 
    When I visit the grant dossier access page 
    And I fill in "eMail-Address" with "[email protected]" 
    And I select "readonly" from "Permissions" 
    And I press "Grant access" 
    Then I should see "Access granted." 
    And I should be on the dossiers page 

    Scenario: Valid data entered with expiry date 
    Given a user "[email protected]" exists 
    When I visit the grant dossier access page 
    And I fill in "eMail-Address" with "[email protected]" 
    And I select "readonly" from "Permissions" 
    And I fill in "Valid until" with "2010-03-01" 
    And I press "Grant access" 
    Then I should see "Access granted till 2010-03-01." 
    And I should be on the dossiers page 

    Scenario: Display calendar on click on "Valid until" 
    When I click on the field "Valid until" 
    Then a calendar popup should be displayed 
    When I click on "1943-01-02" 
    Then the field "Valid until" should be have "1943-01-02" 
    And the calendar popup should be hidden 

    Scenario: Only allow to grant access to categories I have access to myself 
    Given I have limited access to the working dossier 
    When I visit the grant dossier access page 
    Then I should not see categories I have no access to 

    Scenario: Dossier with permission "manager" can only grant readonly, readwrite 
    Given I have the permission "manager" on my working dossier 
    When I visit the grant dossier access page 
    Then I should only see the permissions "readonly, readwrite" 

    Scenario: Dossier with permission "readwrite" is not allowed to grant any permissions 
    Given I have the permission "readwrite" on my working dossier 
    When I visit the grant dossier access page 
    Then I should the see the error "You cannot grant access on this dossier!" 
    And I should be on the dossiers page 

¿cuál prefieren y por qué?

+2

Recuperar esto de la muerte, pero ¿hay alguna razón por la que aún no haya seleccionado una de las respuestas? ¿Qué terminaste yendo con todos modos, y cómo funcionó? – KobeJohn

Respuesta

6

Me gustaría ir con la solución que es más fácil de leer por sus clientes, o personas que no sean desarrolladores, en general. Una gran ventaja de usar herramientas como Pepino es que se lee como una historia. Su objetivo debe ser hacer que cada prueba sea lo suficientemente simple para que un cliente pueda leer sus pruebas de aceptación y darse cuenta de las características que ya están implementadas. Esto lo beneficia porque sus clientes pueden descansar tranquilos sabiendo que ciertas características tienen pruebas de aceptación establecidas.

Dicho esto, creo que la primera solución representa el estilo legible más que la segunda solución.

"Me puede dar acceso a un expediente con una fecha de caducidad"

es más fácil de leer que

"datos válidos introducidos con fecha de caducidad"

en mi opinión.

No es necesario que prefijas cada escenario con "Puedo" o "No puedo", sino que te facilitas al lado de una idea completa.

actualización

En su comentario se preguntó acerca de los errores de validación y cómo se debe manejar eso con la opción 1. Creo que tienes un par de opciones aquí:

  1. pruebas de validación completo en Pepino
  2. Pruebas de validación parcial (los errores se presentan al usuario) en Pepino, y pruebas parciales en RSpec (se arrojan errores) - o algún otro marco de prueba de unidades.

Opción 1

pros:

Usted no tiene que molestarse utilizando otro marco para poner a prueba sus validaciones. La mayoría de tus pruebas se incluirán en Pepino. Sus clientes pueden ver todas sus pruebas en un solo lugar.

contras:

Sus pruebas pepino tendrán diferentes niveles de granularidad incluidos.Sus clientes probablemente se preocupen más por las características de alto nivel que por ver pasar todos los detalles esenciales. Si yo fuera un cliente interesado en utilizar sus pruebas de Cucumber como base para las características que se han implementado y probado, preferiría una lista más pequeña y más legible de casos de prueba que una exhaustiva. Como mucho, probablemente me gustaría ver que los mensajes de error se presentan al usuario, y puede hacerlo en un Esquema de Escenario.

Opción 2

pros:

a separar sus preocupaciones de prueba en los niveles adecuados de granularidad. Como mencioné en los inconvenientes de la Opción 1, lo más probable es que sus clientes estén interesados ​​en las características de nivel más alto que los detalles de nivel más bajo. Puedes probar si las validaciones pasan o no en tus pruebas de unidad RSpec, y usar Cucumber para probar rápidamente que el usuario ve mensajes de error si tienes un registro no válido (otra vez usando contornos de escenarios, o tal vez solo prueba para ver si solo un mensaje de validación al frente). El punto principal es que el Cucumber, más orientado a las pruebas funcionales, no debería probar todo lo relacionado con los Modelos, deje que RSpec u otro marco de prueba unitario lo controle.

contras:

usted tiene que utilizar otro marco para ejercer las expectativas de grano más fino. Usar otro marco implica tomar más tiempo para aprenderlo, etc. También es difícil saber cómo equilibrar cuándo usar un marco sobre el otro, es decir, "¿Debería usar Cucumber o RSpec aquí?"

Por lo que he leído, la opción 2 es la más popular en este momento. Los equipos usan los marcos apropiados para cada nivel de granularidad e intentan mantenerse alejados de un enfoque de "todo incluido".

+0

¿Cómo tratarías con ex. errores de validación? ¿Cómo/dónde describirías qué debería suceder cuando ex. se ingresa una dirección de correo electrónico no válida? ¿No es este comportamiento lo que también es importante? – gucki

+0

@gucki - Actualicé mi respuesta. Espero que este esfuerzo me gane al menos un voto positivo: P – McStretch

4

prefiero el primer tipo de escenario, ya que describe de una manera mejor cómo funciona la característica

Además, usted tiene la refactorización de prueba para hacer allí con el escenario contornos, compruebe esta entrada del blog, es un placer trabajar con pepino http://eggsonbread.com/2010/09/06/my-cucumber-best-practices-and-tips/

en el primer enfoque que tendrá que hacer sus propios pasos, pero se utiliza más veces el mismo escenario y reducir la duplicación de código cuando se tiene:

y siga los pasos de "dirección de correo electrónico" con "[email protected]" Y complete "dirección de eMail" w ith "[email protected]"

en diferentes escenarios. Espero hacer mi punto aquí.

También me encarecidamente que recomiendan the rspec book, y un talk called outside-in development with cucumber

Saludos

+0

Estoy completamente de acuerdo en que las características/escenarios deberían estar secos. Así que comenzaría con un estilo imperativo y luego refactorizaría, dándome un estilo más declarativo (sin perder ninguna prueba de UI ni documentación). Como escribí en otro comentario a continuación, no me gusta el ejemplo 1 porque creo que se parece más a lo que se debe poner en una prueba funcional (... Entonces el usuario "Pascal" debería tener permiso "de solo lectura" en el dosier "Max Müller") . También ignora por completo la interacción del usuario. – gucki

2

El objetivo de este tipo de BDD es proporcionar, características comprensibles legibles para los tomadores de decisiones no técnicas/directores dentro de una organización (para reducir los problemas de comunicación entre los responsables de la toma de decisiones y los implementadores).

Para este fin, el estilo en su primer ejemplo es obvio en el segundo ejemplo. Fácil.

+0

Mi preocupación con el primer ejemplo es que realmente no define el comportamiento que el usuario tiene que enfrentar. Me parece mucho más una prueba funcional. – gucki

+0

Realmente depende de con qué tipo de audiencia (directores) estés tratando. Si están familiarizados con la UI y Ux de su aplicación, entonces el segundo ejemplo es más apropiado. Sin embargo, para aquellos que NO están familiarizados con la UI/Ux, el primer ejemplo es mejor. Si tuviera que elegir entre los dos (sin conocer a mi audiencia), entonces, en mi opinión, este tipo de BDD se entiende más para el último caso (directores no íntimos con la IU), por lo que recomendé ir con el primer ejemplo: - pero si sabes que eres público, ¡por supuesto deberías atenderlos! – JoshuaDavid

1

Prefiero el segundo enfoque de los dos. Aquí están mis preocupaciones con el Enfoque 1.

Cuando conceder el acceso en expediente "Max Müller " a "Pascal" con permisson "sólo lectura"

se puede implementar sin pasar por la interfaz de usuario, que es un peligro. Si lo fuera, hay un nivel completo de expectativas sobre cómo los usuarios otorgan acceso que no se probaría. El pepino brilla desde la interfaz de usuario hasta el final (probando a través de la interfaz de usuario).

tengo la misma preocupación por

Y el usuario "Pascal" debe tener permiso "sólo lectura" en expediente "Max Müller"

Es posible que se ejecuta cada uno de estos pasos en las definiciones de paso, llamando a los pasos que pasan por la interfaz de usuario, pero a menos que eso sea cierto, aún así me preocuparía.

En resumen, me preocupa que el Método 1 no se pruebe a través de la IU.

+0

Oye, eres el único que ha escogido los escenarios de pepino (2. ejemplo) que propuse a nuestro equipo :). En mi opinión, pasar por la IU * una vez * es muy importante. Si no lo hago, ¿cómo debería saber qué campos rellenar y cómo reacciona la aplicación a entradas no válidas, etc.? Podría esconder esto en mis pasos, pero es más feo escribir (no es bueno "... complete lo siguiente:") y también faltaría de la documentación. En las funciones siguientes, no volvería a seguir todos los pasos. En cambio, usaría un paso "Dado que un usuario ... existe", que usa una fábrica en el paso. – gucki

13

El objetivo de las pruebas de Cucumber es crear una especificación sobre lo que hace el código que pueda leer la gente de su equipo que no pueda leer el código. Comenzaría preguntándoles cuál prefieren.

Supongo que preferirán la primera porque es más declarativa. Debido a que está escrito en un nivel más alto de abstracción (en lugar de preocuparse por hacer clic en widgets en una página) es más fácil de leer.

Al contrario de lo que dijo Josh, creo que tener pasos que podrían funcionar ya sea a través de una IU o no es una muy buena idea. La aparición de problemas de UI en una característica puede hacer que sea frágil para los cambios de diseño legítimos, y también un poco aburrido de leer.

hice una charla recientemente sobre este tema, creo que es realmente relevante a donde estás: http://skillsmatter.com/podcast/agile-testing/refuctoring-your-cukes

Véase también estas entradas de blog relevantes:

¡Buena suerte!

+1

Gracias por su respuesta. Vi tu charla y no estoy realmente convencido de cómo se caracterizan/escenarios. A las 7:30, está escribiendo una función llamada "Registrarse" que tiene los escenarios "Solicitar una cuenta", "Confirmar cuenta" y "Completar el perfil de la cuenta". En mi opción, estos no son escenarios, sino funciones separadas. Al tener una "función Crear", puedo especificar exactamente los escenarios que pueden ocurrir cuando creo una cuenta (enviar datos válidos, enviar datos inválidos, bloquear la IP si se crean demasiadas cuentas dentro de un tiempo, ...). – gucki

+1

... continuación: Imo "confirmar cuenta" es un paso/característica adicional, que necesita una explicación (¿por qué deseo que los usuarios confirmen su cuenta?). También puedo agregar diferentes escenarios: la confirmación de la cuenta ya ha expirado, presentar un formulario que debe completarse, etc. – gucki

5

El primer conjunto es el claro ganador si se ajusta a los estándares de los fabricantes de pepino.

Esta publicación de blog, "The training wheels came off" de (uno de?) El fabricante de pepino (Aslak Hellesøy), apunta directamente a la diferencia entre las dos opciones que usted escribió. En términos muy claros, explica que las características declarativas, enfocadas en el dominio, fáciles de entender son lo que los usuarios de pepino deberían tratar de lograr y que hacen que su opción 1 sea la ganadora.

básicamente Dice que trata de lograr DRY funcionales pasos en el idioma del sistema (haga clic en este, seleccionar esa, etc.) son un olor código en Pepino.En sus palabras:

Si todo lo que necesita es una herramienta de prueba para la conducción de un ratón y un teclado, no utilizan pepino. Hay otras herramientas diseñadas para hacer esto con mucha menos actividad de abstracción y escritura que Cucumber.

Por cierto, muchas personas aquí han dicho que el propósito de Cucumber es facilitar la lectura y la comprensión para el cliente. Creo que está un poco fuera de objetivo y la facilidad de comprensión no es el propósito. Creo que crearon Cucumber para garantizar que el cliente y el desarrollador hablen el mismo idioma y trabajen para obtener los mismos resultados. Entonces, se trata tanto de hacer que los desarrolladores se pongan en la piel del cliente como de ayudar al cliente a ver el proceso de desarrollo.

Cuestiones relacionadas