# Behaviour Driven Development
BDD > Definición
### *Metodología* de desarrollo de software en el que *se especifica y diseña* una aplicación *mediante la descripción de su comportamiento* para un observador externo.
BDD es TDD sin que sea necesario que todo el equipo del proyecto tenga conocimientos de programación
BDD > Definición > En pocas palabras
### **Usar ejemplos** en múltiples niveles para crear un **entendimiento compartido** para entregar **software de valor**
BDD
# Beneficios en su aplicación
BDD > Beneficios en su aplicación
## Es acerca de compartir comportamientos esperados entre todos los miembros del proyecto
## Focaliza el esfuerzo en comprender las reglas del negocio
## Mejora el entendimiento de los requerimientos (incluso para el cliente)
## *Build the right software*
## Releases más confiables
BDD
# Desafíos para su aplicación
BDD > Desafíos para su aplicación
## Requiere compromiso y colaboración de Stakeholders, BA y/o Product Owner
## Escribir escenarios útiles requiere práctica
BDD
Usar ejemplos en
múltiples niveles para crear un entendimiento compartido
para entregar software de valor
BDD > Usando ejemplos
## Ventajas
* Exploramos los requerimientos
* Descubrimos lo que no sabemos
* Clarificamos ambigüedades
* Identificamos asunciones y desentendidos
#### Ejemplo 1 - Escenarios del Piedra, Papel o Tijera
```text
Scenario: PIEDRA vs PAPEL
Given jugadorUno juega PIEDRA
When jugadorDos juega PAPEL
Then gana jugadorDos
```
También se puede generalizar
```text
Scenario Outline: jugadorUno vs jugadorDos
Given jugadorUno juega <elementoUno>
When jugadorDos juega <elementoDos>
Then <resultado>
Examples:
| elementoUno | elementoDos | resultado |
| PIEDRA | PAPEL | gana jugadorDos |
| PIEDRA | PIEDRA | hay empate |
| PAPEL | PIEDRA | gana jugadorUno |
```
#### Ejemplo 2 - Escenarios del Frequent Flyer
```text
Scenario: New members should start out as Bronze members
Given Jill Smith is not a Frequent Flyer member
When she registers on the Frequent Flyer program
Then she should have a status of Bronze
```
```text
Scenario Outline: Members should get status updates based on status points earned
Given a member has a status of <initialStatus>
And he has <initialStatusPoints> status points
When he earns <extraPoints> extra status points
Then he should have a status of <finalStatus>
Examples:
| initialStatus | initialStatusPoints | extraPoints | finalStatus |
| Bronze | 0 | 300 | Silver |
| Silver | 0 | 700 | Gold |
| Gold | 0 | 150 | Platinum |
```
#### Ejemplo 3 - Escenarios del conversor de monedas
```text
Scenario Outline: Comprador cambia pesos por dolares
Given comprador paga <pesos> pesos
When el tipo de cambio es <cambio>
Then comprador adquiere <dolares> dólares
Examples:
| pesos | cambio | dolares |
| 150 | 10.7 | 1605 |
| 300 | 9.5 | 2850 |
| 590 | 9.9 | 5841 |
```
BDD
Usar ejemplos en múltiples niveles
para crear un entendimiento compartido
para entregar software de valor
BDD > Entendimiento compartido
### Muchos equipos contruyen software de esta manera
### _Three amigos_
BDD
Usar ejemplos en múltiples niveles
para crear un entendimiento compartido para entregar
software de valor
BDD > Software de valor
### Comenzamos con un objetivo de negocio
### ¿Qué _features_ nos permitirán lograr este objetivo?
### Usamos _conversaciones_ en torno a ejemplos para construir nuestro entendimiento sobre los _features_
### Podemos automatizar estos ejemplos en forma de _especificaciones ejecutables_
### Usamos de BDD a bajo nivel o TDD para definir el comportamiento de los componentes
Cucumber
## Describe comportamiento en texto plano
## Es un framework de BDD
## Genera documentación del comportamiento de la aplicación
Cucumber > Implementaciones
* ### Ruby
* ### Java
* ### Groovy
* ### JavaScript
* ### .NET
* ### PHP
* ### C++
Cucumber > Componentes
Cucumber > Mandamientos
## Los escenarios deben conducir la implementación, no reflejarla
## Los escenarios deben ser escritos antes que el código que implementan dichos _features_
Cucumber
## Componentes de un .feature
Cucumber > Componentes de un .feature
## FEATURE
### Describe brevemente el comportamiento esperado
## BACKGROUND
### Indican uno o más pasos que se ejecutarán antes de cada escenario
## SCENARIO
### Es un caso particular de prueba
## SCENARIO OUTLINE
### Es un template para realizar un conjunto de pruebas generalizadas
## GIVEN
### Indica el cumplimiento de una precondición determinada
## WHEN
### Indica el suceso de un evento determinado
## THEN
### Indica una consecuencia determinada
## No importa el orden `;)`
Caso de estudio > Shopbeam
Caso de estudio > Shopbeam > Herramientas
## Capybara + Watir (u otro)
* ### Es un framework que ayuda a realizar tests de aceptación sobre aplicaciones web, simulando como un usuario real interactua con ella (web automation)
* ### Es agnostico acerca del motor que estamos utilizando para correr los tests
* ### WATIR = Web Application Testing in Ruby
## FactoryGirl
* ### Es una librería que permite definir objetos (en Ruby) para utilizar como información para nuestros tests
* ### Permite tener fixtures de los cuales valernos para los tests que tenemos definidos
Caso de estudio > Shopbeam
