BDD - TDD en forma de BDD
En TDD, el término "Pruebas de aceptación" es engañoso. Las pruebas de aceptación realmente representan el comportamiento esperado del sistema. En las prácticas ágiles, se enfatiza la colaboración de todo el equipo y las interacciones con el cliente y otras partes interesadas. Esto ha dado lugar a la necesidad de utilizar términos que sean fácilmente comprensibles para todos los involucrados en el proyecto.
TDD te hace pensar en lo necesario Behavior y por lo tanto el término 'Comportamiento' es más útil que el término ‘Test’. BDD es un desarrollo basado en pruebas con un vocabulario que se centra en el comportamiento y no en las pruebas.
En palabras de Dan North, "Encontré el cambio de pensar en las pruebas a pensar en el comportamiento tan profundo que comencé a referirme a TDD como BDD, o desarrollo impulsado por el comportamiento". TDD se centra en cómo funcionará algo, BDD se centra en por qué lo construimos.
BDD responde a las siguientes preguntas a las que a menudo se enfrentan los desarrolladores:
| Pregunta | Responder |
|---|---|
| ¿Donde empezar? | de fuera hacia dentro |
| ¿Qué probar? | Historias del usuario |
| ¿Qué no probar? | Algo más |
Estas respuestas dan como resultado el marco de la historia de la siguiente manera:
Story Framework
Como un [Role]
quiero [Feature]
así que eso [Benefit]
Esto significa, 'Cuando un Feature se ejecuta, el resultado Benefit es para la persona que juega el Role.'
BDD responde además a las siguientes preguntas:
| Pregunta | Responder |
|---|---|
| ¿Cuánto probar de una vez? | muy poco enfocado |
| ¿Cómo llamar a sus pruebas? | plantilla de oración |
| Cómo entender por qué falla una prueba | documentación |
Estas respuestas dan como resultado el marco de ejemplo de la siguiente manera:
Example Framework
Given algún contexto inicial,
When ocurre un evento,
Then asegurar algunos resultados.
Esto significa, 'Comenzando con el contexto inicial, cuando ocurre un evento en particular, sabemos cuáles son los resultados should be.
Así, el ejemplo muestra el comportamiento esperado del sistema. Los ejemplos se utilizan para ilustrar diferentes escenarios del sistema.
Historia y escenarios
Consideremos la siguiente ilustración de Dan North sobre un sistema de cajeros automáticos.
Historia
As a cliente,
I want retirar efectivo de un cajero automático,
so that No tengo que hacer cola en el banco.
Escenarios
Hay dos escenarios posibles para esta historia.
Scenario 1 - La cuenta está en crédito
Given la cuenta está en crédito
And la tarjeta es válida
And el dispensador contiene efectivo
When el cliente solicita efectivo
Then asegúrese de que la cuenta esté cargada
And asegúrese de que se distribuya efectivo
And asegúrese de que la tarjeta sea devuelta
Scenario 2 - La cuenta está sobregirada más allá del límite de sobregiro
Given la cuenta está sobregirada
And la tarjeta es válida
When el cliente solicita efectivo
Then asegúrese de que se muestre un mensaje de rechazo
And asegúrese de que no se dispensa efectivo
And asegúrese de que la tarjeta sea devuelta
El evento es el mismo en ambos escenarios, pero el contexto es diferente. Por tanto, los resultados son diferentes.
Ciclo de desarrollo
El ciclo de desarrollo de BDD es un outside-in Acercarse.
Step 1- Escriba un ejemplo de valor comercial de alto nivel (externo) (utilizando Pepino o RSpec / Carpincho) que se ponga rojo. (RSpec produce un marco BDD en el lenguaje Ruby)
Step 2 - Escriba un ejemplo de RSpec de nivel inferior (interior) para el primer paso de implementación que se pone rojo.
Step 3 - Implementar el código mínimo para pasar ese ejemplo de nivel inferior, ver cómo se vuelve verde.
Step 4 - Escriba el siguiente ejemplo de RSpec de nivel inferior presionando para pasar el Paso 1 que se pone rojo.
Step 5 - Repita los pasos del Paso 3 y el Paso 4 hasta que el ejemplo de alto nivel del Paso 1 se vuelva verde.
Note - Deben tenerse en cuenta los siguientes puntos:
Red/green estado es un estado de permiso.
Cuando sus pruebas de bajo nivel son verdes, tiene permiso para escribir nuevos ejemplos o refactorizar la implementación existente. No debe, en el contexto de la refactorización, agregar nueva funcionalidad / flexibilidad.
Cuando sus pruebas de bajo nivel son rojas, tiene permiso para escribir o cambiar el código de implementación solo para que las pruebas existentes se vuelvan verdes. Debe resistir la tentación de escribir el código para aprobar su próxima prueba, que no existe, o implementar características que pueda pensar que son buenas (el cliente no lo habría pedido).