Mejores prácticas de BDD para diseñar escenarios de pepino para los formularios

Question

Digamos que tiene un formulario que crea un nuevo usuario. ¿Cómo se escribe el escenario de Pepino?

1.)

Given I am logged in as admin 
When I create a new user 
Then I should see "Successfully created user" 

2.)

Given I am logged in as admin 
When I go to Create new user 
And I fill in "Name" with "Name111" 
And I fill in "Password" with "Password111" 
And I press "Create new user" 
Then I should see "Successfully created user" 

Si elige 1.) ¿dónde documentar los requisitos para un usuario (el usuario debe tener un nombre y una contraseña) . Veo que BDD tiene que ver con el comportamiento, pero en algún momento usted y el interesado deben especificar qué propiedades debe tener un usuario, ¿no es así?

que soy muy nuevo en el TDC, entonces, agradezco cualquier consejo ...

Answer 1

Debe leer Imperative vs Declarative Scenarios.

--Aslak. Creador de Pepino.

Answer 2

Cualquiera de los dos va a funcionar. Con # 1 crearía un paso para manejar el llenado del formulario. Yo prefiero un híbrido de # 1 y # 2 porque uso Escenario esboza un montón por ejemplo:

Background: 
Given the following users exist: 
    | email    | password  | 
    | test@example.com | testpassword23 | 
    | test2@example.com | notthistime  | 
    | test3@example.com | welcomeback  | 

    @login @authentication 
    Scenario Outline: Authentication 
    Given I am on the new user session page 
    When I login with "<s_email>" and "<s_password>" 
    And I press "Login" 
    Then I should see "<s_message>" 

    Examples: 
    | s_email   | s_password  | s_message      | 
    | test@example.com | testpassword23 | Signed in successfully   | 
    | test2@example.com | itriedreallyhard | Invalid email or password.  | 
    | teOst@example.com | testpassword23 | Invalid email or password.  | 

Answer 3

Los escenarios que has escrito son bastante bajo nivel. A menos que esté realmente produciendo una funcionalidad de inicio de sesión segura para vender, me quedaré con el caso feliz y la unidad/manual probará el resto. Si no lo haces, crearás tantos escenarios que será una pesadilla de mantenimiento.

Estudia lo que diferencia el producto que está creando de todos los productos similares, a continuación, apuntar que a medida que el valor del escenario. A continuación, se vería así:

Given Fred is logged in 
When Fred <does something> 
Then Fred should <get some really differentiating value> 
And <something else happens> 

Se adhieren a las capacidades de muy alto nivel, en lugar de medidas basadas en formularios de bajo nivel. Por ejemplo:

Given there is already a question on BDD and Cucumber 
Given Peyote is logged in 
When Peyote proposes a question on BDD and Cucumber 
Then Peyote should see other questions on BDD and Cucumber. 

Hay un concepto llamado "Página paradigma", en el que se crea una clase con todos los pasos de bajo nivel que la página o pantalla pueden realizar. A continuación, puede llamar a esos pasos de bajo nivel en la página desde los dispositivos de paso de Pepino de nivel superior.

su negocio será mucho más comprometidos con los escenarios de este tipo. El objetivo principal de BDD no es producir pruebas automatizadas, sino tener conversaciones sobre los escenarios para que pueda averiguar dónde se está equivocando y qué otras opciones podría considerar antes de tomarse la molestia de implementar el código. Las pruebas automatizadas son un buen subproducto.

Las conversaciones y el aprendizaje que se obtiene al hablar a través de ellos, son las cosas que hacen diferente de BDD ATDD (Test Driven Development Aceptación). Es por eso que usamos un lenguaje como Ejemplo, Escenario, Dado, Cuándo, Luego, Contexto, Evento, Resultado en lugar de Prueba, Configuración, Desprendimiento, Actuar, Arreglar, Afirmar - entonces podemos hablar de esto con los negocios, BA y probadores en el mismo idioma.

Ver Dan North's article on Deliberate Discovery y el resto de su blog para más, y buena suerte con la BDD!