El BDD se presenta como una opción para poder desarrollar de forma más efectiva al permitirnos especificar los requerimientos de nuestros clientes de forma precisa y que su verificación una vez implementados sea de forma automatizada. Mejora nuestras prácticas al forzarnos a pensar en el código que desearíamos tener para satisfacer los requerimientos de nuestros clientes, esto germina en que tengamos aplicaciones mejor organizadas con APIs más claras y que implementemos a las interfaces/contratos de responsabilidad y colaboraciones entre los diversos objetos del sistema. Pero el contar con herramientas no es suficiente, el desarrollar una técnica efectiva es fundamental para que se tengan los beneficios del BDD. En alguna época los médicos no se lavaban las manos antes de una cirugía por que lo consideraban una perdida de tiempo, ahora esto es impensable. Llegará el día en que se hará impensable el desarrollar un sistema sin BDD, hagamos que muy pronto sea ese día.

1. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

2. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

3. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

4. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

5. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

6. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

7. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

8. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

9. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

10. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

11. So6ware
by
Numbers:
Low-­‐Risk,
High-­‐Return
Development.
By
Mark
Denne,
Jane
Cleland-­‐Huang.
Pren%ce
Hall
PTR.
October
10,
2003
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

12. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

13. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

14. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

15. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

16. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

17. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

18. Cliente
que
%ene
una
meta
con
un
valor
Interfaz
de
Usuario
WUI/GUI
vistas
controladores
modelos
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

19. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

20. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

21. RSpec
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

22. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

23. RSpec
“Los
vistas
componentes
e
controladores
interacciones
modelos
que
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

24. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

25. RSpec
“Los
componentes
e
interacciones
que
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

26. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

27. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

28. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

29. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

30. Feature:
[Título
de
la
caracterís%ca
]
In
order
to
[Valor
de
Negocios]
As
a
[Role]
I
want
[la
acción
que
da
el
valor]
No
se
ejecuta
Su
valor
es
documental
El
valor
de
negocios
se
hace
explicito
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

31. Scenario:
[Título
del
escenario
de
uso]
Given
[Contexto
-­‐
Precondición]
When
I
[do]
[Acción]
Then
I
should
[see]
[Resultado]
Ejecutable
mediante
los
steps
Valor
de
diseño
El
resultado
esperado
es
explicito
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

32. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

33. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

34. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

35. RSpec
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

36. RSpec
describe
[Class]
do
context
[Contexto]
do
it
[ejemplo
de
especificación]
<code>
end
end
end
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

37. RSpec
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

38. RSpec
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

39. RSpec
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

40. RSpec
“Los
componentes
e
interacciones
que
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

41. RSpec
“Los
componentes
e
interacciones
que
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

42. RSpec
“Los
componentes
e
interacciones
que
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

43. RSpec
“Los
componentes
e
“Soporta
todas
las
simulaciones
de
interacciones
que
navegador”
desearía
tener”
API
y
DSL
similar
a
Webrat
Puede
cambiar
los
simuladores
Navegación,
Clic
de
ligas
y
botones
Interacción
con
formas
Consultas
y
busquedas
Alcances
y
scripWng
Soporta
XPath
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

44. RSpec
“Los
componentes
e
“Soporta
todas
las
simulaciones
de
interacciones
que
navegador”
desearía
tener”
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

45. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

46. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

47. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

48. SRP:
Single
Responsibility
Principle
Connascence
OCP:
Open
Closed
Principle
Cuando
dos
cosas
nacen
y
crecen
LSP:
Liskov
SubsWtuWon
Principle
Juntas.
ISP:
Interface
SegregaWon
Principle
DIP:
Dependency
Inversion
Principle
Cuando
hay
connascence
entre
A
y
B
Todo
cambio
en
A
requiere
un
cambio
en
B
para
preservar
lo
correcto
y
viceversa
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

49. SRP:
Single
Responsibility
Principle
Principio
de
una
Sola
Responsabilidad
No
debería
nunca
haber
más
de
una
razón
para
que
una
clase
cambie
OCP:
Open
Closed
Principle
Principio
de
abierto
cerrado
So6ware
de
enWdades
(clases,
módulos,
funciones,
etc.)
Deben
estar
abiertos
a
la
extensión
pero
cerrado
por
modificación
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

50. LSP:
Liskov
Subs9tu9on
Principle
Principio
de
subs%tución
de
Liskov
Funciones
que
usen
...
referencias
a
una
clase
base
deben
ser
capaz
de
uWlizar
objetos
de
clases
derivadas
de
la
base
sin
saberlo
ISN:
Interface
Segrega9on
Principle
Principio
de
segregación
de
interfaces
los
clientes
no
se
vean
obligados
a
depender
de
interfaces
que
no
uWlizan
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

51. DIP:
Dependency
Inversion
Principle
Principio
de
inversión
de
dependencia
A.
Módulos
de
alto
nivel
no
deben
depender
de
módulos
de
bajo.
Ambos
deben
depender
de
abstracciones
B.
Abstracciones
no
deberen
depender
de
detalles.
Detalles
debeben
de
depender
abstracciones
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

52. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

53. “Simulador
de
“Soporta
todas
las
RSpec
“Los
componentes
e
navegador
muy
simulaciones
de
interacciones
que
rápido”
navegador”
desearía
tener”
Gracias
a
todas
las
personas
que
han
contribuido
para
que
podamos
contar
con
estas
magnificas
herramientas
y
métodos
“La
caracterís*ca
que
desearía
tener”
Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre

54. Manuel
Vidaurre

manuel.vidaurre@agiltec.com.mx

@mvidaurre