1,2,3 Probando
Acercando BDD a las masas
Ricardo Markiewicz
<gazer.arg@gmail.com>

Evolución

¿Por qué “testear”?
● Confianza
– Manual
– Automático

¿Por qué automatizar?
● Confianza
– Test de regresión
● Refactoring
– Agilidad al cambio
Se pueden escribir test
antes o después, ambos
dan el mismo nivel de
confianza

Test Driven Development
● Plantea escribir Test,
luego código
● Desarrollo evolutivo
● El diseño emerge
durante el desarrollo
– No hay diseño previo
● Tiende al desastre en la
mayoría de los casos :)

El problema de TDD
● TDD != escribir los tests primeros
● TDD =~ escribir los test primeros
● TDD no es acerca de escribir tests
● TDD es acerca de diseño
● TDD es una metodología de diseño, no de
pruebas.

Behaviour Driven Development
● Hacer TDD y entender de que se trata cada
cosa es difícil
● BDD ayudar a centrar el desarrollo
– Verificable con valor empresarial
– Lenguaje común entre el cliente y los
desarrolladores
● BDD es una reformulación de las buenas
prácticas existentes, no se trata de un nuevo
punto de partida radical.

Proceso BDD
● Relevamiento de características a realizar.
– Se habla con el cliente
● Se escriben historias de la forma
Como Role Como un cliente, quiero sacar
Quiero Feature dinero del cajero automático, de
De modo que Benefit modo que no necesite pasar
tiempo en la cola.
● Beneficios : El cliente entiende que es lo que
se va a desarrollar
● Criterio de aceptación ejecutable

Historias
● Una historia luego se desglosa en diferentes
escenarios.
● Cada escenario define una acción especifica
para cumplir con la característica pactada.
● El escenario se describe en lenguaje coloquial,
por lo que el cliente lo entiende, describiendo
los pasos para lograrlo.

Historia : Sumas algebraicas
Caracteristica: Sumas algebraicas
Como un estudiante
quiero sumar números
de modo que el resultado en mis exámenes sea correcto.
Escenario: Suma de dos números positivos
Dado que tengo una calculadora
Cuando sumo “2” y “2”
Entonces debo ver “4”

BDD Cicle
● Doble red-green-
refactor
● Primero historias
● Despues tests
específicos

Cucumber : History Runner
● Intérprete de Historias hecho en Ruby
● Permite definir qué significa a nivel de
programa cada frase de un escenario
Dado /^que tengo una calculadora$/ do
@calc = Calc.new
end
Cuando /^sumo “(\\d)” y “(\\d)”$/ do |n1, n2|
@calc.sumar(n1, n2)
end
Entonces /^debo ver “(\\d)”$/ do |expected|
@calc.result.should == expected
end

Lo que deben estar pensando
● Estuve 2 días para implementar un simple
método
● Mi capacidad de producción está por el piso
● ¡No llego nunca a la fecha de entrega!

Lo que deberían saber
● BDD es un proceso de desarrollo de software :
hay que aprenderlo y madurarlo, así como una
vez aprendimos a programar en objetos
● Facilidad para pautar metas con los clientes
– Si se que hago 1 features por día, y tengo que
hacer 20 features, tardo 20 días :)
● Buena documentación de como se usa el
código escrito
● Código en constantes evolución, nunca hay
retroceso

Herramientas
● Existen para Java, .NET, Ruby, Python, C, C++,
AS3, Delphi, javascript, Scala, PHP
● Sitios
– http://en.wikipedia.org/wiki/Behavior_Driven_Developme
– http://www.behaviour-driven.org

Muchas Gracias
¿Preguntas?
Ricardo Markiewicz
<gazer.arg@gmail.com>
http://www.twitter.com/gazer_arg/
http://www.gazer.com.ar/