testing - then - ¿Es aceptable escribir una prueba de "Dado cuándo, entonces, cuándo" en Gherkin?

scenario outline cucumber java

Question

¿Es aceptable escribir una prueba "Dado cuándo, entonces, cuándo" en Gherkin? Un ejemplo de la vida real es el siguiente AllPlayers.com

Scenario: Successfully register a user
Given I am on homepage
And I am not logged into an account
When I follow "create a new account"
And I fill in "First Name" with "Bobby"
And I fill in "Last Name" with "Bricks"
And I fill in "E-mail" with "[email protected]"
And I select "Jun" from "Birthday Month"
And I select "22" from "Birthday Day"
And I select "1985" form "Birthday Year"
And I select "Male" from "Gender"
And I fill in "Password" with "123testing"
And I fill in "Confirm Password" with "123testing"
And I solve the captcha math problem
And I click "Create new account"
Then I should see "the user dashboard"
And I should see the Registration Wizard
When I push "Proceed to next step"
Then the "First Name" field should contain "Bobby"
And the "Last Name" field should contain "Bricks".

Sé que funciona utilizando behat, por lo que analizarlo no es un problema. Solo estoy tratando de escribir mejores pruebas. Podría escribir el primero And the Registration Wizard should be filled out with data luego And the Registration Wizard should be filled out with data pero eso no parece lo suficientemente específico ...

Sugerencias?

Answer 1

Depende de la audiencia objetivo de la característica como está escrito. Parece muy probable que el pepinillo que tiene allí no se haya escrito con un interesado (es decir, alguien que no tenga experiencia técnica pero que tenga un gran interés en el negocio y el sitio web). BDD realmente trata sobre la conversación sobre los requisitos y las expectativas, y Gherkin es una herramienta que ofrece una forma estándar / reconocida de que todos deben poder leer y escribir los requisitos y expectativas; de una manera que sirve como pruebas automatizadas para un desarrollador y tal vez scripts de prueba para un probador.

Tratando de quitarme la cabeza a mi desarrollador ahora, diría que un actor de negocios preferiría leer y entender fácilmente ...

Scenario: Should be able to successfully register on website
Given I am new to the website
And I want to register for a user account
When I go to the registration form
And I complete all the required registration details correctly
Then I will be registered on the website
And I will be automatically logged in

Aún puede realizar la misma prueba detrás de escena de esta especificación, pero esta especificación tiene un número mayor de lectores, es un requisito más fácil de entender que cualquier persona debería entender. No estoy diciendo que lo que tienes no tiene valor, ni mucho menos. Será una prueba muy válida. Pero es bastante específico para el desarrollador, y está altamente acoplado a la implementación de la interfaz de usuario (si refactoriza / rediseña la interfaz de usuario, ahora necesita refactorizar sus requisitos ...).

Comencé a tener muchas especificaciones de pepinillos muy parecidas a las suyas, y aún las uso en ocasiones. Una vez que su marco de prueba haya construido un poco de pepinillo es una manera realmente excelente de escribir pruebas unitarias basadas en datos / configurables; y todavía tienen un gran valor para mi proceso de desarrollo. Pero sí trato de separar las especificaciones más "puras" de mis "desarrolladores", pero la carpeta y las etiquetas / categorías.

Edit: Supongo que en resumen a lo que me refiero es ... lo que tienes es una gran "prueba", pero un "requisito" bastante malo. Quédate con eso sin embargo!

Answer 2

Sí, más de un ciclo When / Then es apropiado en un escenario de Gherkin cuando el escenario del mundo real lo requiere.

La respuesta de SaxonMatt destaca que los escenarios se escriben mejor en el lenguaje de las partes interesadas que en el lenguaje de la manipulación de la interfaz de usuario, y que al hacerlo a menudo reduce la duración de un escenario, pero eso omite el punto exacto de la pregunta. Tomemos el toro por los cuernos.

Gherkin se diseñó para las pruebas de aceptación: pruebas que prueban que los requisitos a nivel de las partes interesadas se han implementado completamente, es decir, que el software realmente proporciona valor a las partes interesadas. A veces, proporcionar valor requiere más de un ciclo de acción-respuesta. Considere el siguiente escenario:

Scenario: Guest buys a product
# This scenario starts with the user not logged in, which doesn''t require a step
Given there is a product named "Elliptical Juicer"
When I go to the product page for "Elliptical Juicer"
And I add the product to my shopping cart
Then I should see 1 product in my shopping cart
When I request to check out
Then I should see the account creation form
When I create an account
Then I should see the checkout form with 1 product, "Elliptical Juicer"
When I check out
Then I should see the checkout success page with 1 product, "Elliptical Juicer"
And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"

(Tenga en cuenta que cuando tengo más de un ciclo When / Then en un escenario, me gusta separarlos con líneas en blanco para que se destaquen).

Hay varias razones por las que este escenario se escribe mejor con varios ciclos de When / Then :

• Antes de que el usuario realice el check out, debe ver un producto en su carrito de compras (solo como un dígito en el encabezado del sitio, por lo que el paso no menciona el nombre del producto). No hay manera de probar este requisito al final del escenario. (Bueno, la prueba podría recopilar la información inmediatamente después de que el usuario agregue el producto a su carrito y afirmar el recuento esperado al final del escenario, pero eso sería inútil y confuso). En cambio, afirme el recuento correcto en el punto natural. lugar en el escenario, tan pronto como sea visible para el usuario.

  Del mismo modo, Then I should see the account creation form y Then I should see the checkout form with 1 product, "Elliptical Juicer" puede probar requisitos importantes en los puntos del escenario en el que es natural probarlos.

• Supongamos que no nos importa lo que ve el usuario durante el proceso, solo si llegan al final del escenario con su producto en camino. Entonces podríamos omitir los pasos intermedios de Then :

  Given there is a product named "Elliptical Juicer"
  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  And I request to check out
  And I create an account
  And I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"

  And I create an account es una sorpresa, ¿no es así? Requiere que el lector deduzca que se le pide a un usuario invitado que cree una cuenta durante el proceso de pago. Es más claro decirlo explícitamente, como en la primera versión del escenario que presenté.

• Supongamos que ninguna de las preocupaciones anteriores nos convenció y escribimos un escenario Gherkin separado para cada punto del escenario general en el que debíamos afirmar que se cumplieron los requisitos:

  Scenario: Guest adds a product to their shopping cart
  Given there is a product named "Elliptical Juicer"
  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  Then I should see 1 product in my shopping cart
  Scenario: Guest with a product in their shopping cart attempts to check out
  Given I have a product in my shopping cart
  When I request to check out
  Then I should see the account creation form
  Scenario: Guest creates an account
  Given I have a product named "Elliptical Juicer" in my shopping cart
  And I am on the account creation form
  When I create an account
  Then I should see the checkout form with 1 product, "Elliptical Juicer"
  Scenario: Newly registered user checks out
  Given I am a user
  And I have a product named "Elliptical Juicer" in my shopping cart
  And I am on the checkout form
  When I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"

  ¡Eso es horrible! Primero, ninguno de los escenarios es lo que un actor consideraría como un escenario. Segundo, cuando uno de los estados intermedios cambia, dos pasos tendrán que cambiarse: el paso que afirma el estado intermedio y el paso que establece el estado intermedio para el siguiente escenario. Cada uno de esos pasos Given es una oportunidad para configurar el estado incorrecto, es decir, cometer un error de integración. Este conjunto de escenarios tiene mucho menos valor como conjunto de pruebas de integración que el escenario único. Es posible que casi hayas escrito una serie de pruebas unitarias.

Es cierto que escribir cada escenario de extremo a extremo puede llevar a alguna duplicación. Al igual que tolera la duplicación más en las pruebas unitarias de lo que lo haría en el código normal, tolere la duplicación aún más en los escenarios Gherkin que en las pruebas unitarias. No comprometa la comprensibilidad. Divida los escenarios y use Given s solo en puntos cruciales (como la creación de un producto en el ejemplo anterior) y hágalo sabiendo que está diluyendo el poder de prueba de integración de sus escenarios.

Además, tenga en cuenta que las pruebas de aceptación deben ser solo una parte de su conjunto de pruebas automatizadas. Escriba solo pruebas de aceptación suficientes para cubrir escenarios críticos y cubra los detalles con pruebas unitarias. Con frecuencia, la solución a la duplicación entre las pruebas de aceptación es reemplazar una con una prueba de unidad.

Answer 3

Yo diría que no.

Cuando una prueba falla, debería indicarle en qué parte del sistema se produjo la falla. Las pruebas largas como en su ejemplo tienden a ser frágiles y requieren un mayor nivel de mantenimiento.

Necesita definir qué prueba está evaluando (lo que debería ser una cosa) leyendo su prueba

• Podría ser una prueba de validación de formularios.
• Podría ser una prueba de registro.
• Podría ser una prueba de panel de usuario.

Requeriría una cantidad de tiempo para investigar dónde está la falla y dónde se relaciona eso en el código.

Answer 4

Yo también diría que no

El Dado es una condición previa para la configuración. The When es una acción (que puede ser una acción de no hacer nada) El formulario Then afirma.

Si necesitas más acciones, rompe la prueba.

Esto será mucho más útil una vez que los primeros Then fallan para localizar los problemas.

Answer 5

Yo también diría que no

En otro post mío, Daniel F encontró este artículo fantástico. Aquí está la sección correspondiente:

Los pasos Dados cuando es necesario deben aparecer en orden y no pueden repetirse. A Dado puede no seguir un Cuándo o Entonces, y un Cuándo no puede seguir un Entonces. La razón es simple: cualquier par único When-Then denota un comportamiento individual. Esto hace que sea fácil ver cómo, en la prueba anterior, hay dos comportamientos cubiertos: (1) buscar desde la barra de búsqueda, y (2) realizar una búsqueda de imágenes. En Gherkin, un escenario cubre un comportamiento. Por lo tanto, debe haber dos escenarios en lugar de uno. Cada vez que desee escribir más de un par When-Then, escriba escenarios separados en su lugar. (Nota: algunos marcos BDD pueden permitir pasos desordenados, pero sin embargo serían anti-comportamiento).

https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/