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.
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
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
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
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
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
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
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
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