Este documento describe diferentes técnicas de desarrollo de software, incluyendo desarrollo tradicional, pruebas automatizadas, Test-First, TDD, BDD y cómo complementar BDD con otras técnicas. El autor recomienda comenzar con BDD y complementarlo con REPLs, Spikes y pasos más largos cuando sea necesario para abordar casos difíciles o de alto riesgo. El autor ha ganado menos errores, más constancia, más seguridad y velocidad al adoptar este enfoque flexible.
8. objetivos
del desarrollo de software
1. hace lo que tiene que hacer y no otra cosa!
2. funciona sin fallos!
3. no rompe lo que ya funcionaba!
4. fácil de adaptar a nuevas funcionalidades
10. tradicional
• planificación y estudio de requisitos
• desarrollo: diseño e implementación
• pruebas: QA (Quality Assurance)
11. pruebas (QA)
• “hace lo que tiene que hacer y no otra cosa”:
Pruebas de Aceptación
• “funciona sin fallos”:
Pruebas de Exploración
• “no rompe lo que ya funcionaba”:
Pruebas de Regresión
12. lo que más molesta
del enfoque tradicional
demasiadas pruebas
(no se hacen)
14. tipos de tests
de Aceptación:
comprueba funcionalidad
de Regresión:
nos alerta si hemos roto algo anterior
Unitarios:
componente (aislado) funciona bien
23. TDD
• el objetivo es el código de producción,
los tests son una herramienta para ese objetivo
• que los tests sirvan como pruebas es
secundario
• se basa en repetición de un ciclo básico
24. ciclo básico
de TDD
1. escribir un nuevo test y verificar que falla
2. implementar lo mínimo para que:
A. cambie el mensaje del error
B. pase el test
3. repetir el punto 2 hasta que pase el test
4. refactorizar, sin cambiar comportamiento
26. Red - Green - Refactor
Green
Red Refactor
⇧ funcionalidad ⇧ diseño
seguimos
27. bases de TDD
• tests concisos
• se prueba nuestro código público
• antes de iniciar algo nuevo, dejar en verde
• Diseño Emergente: al escribir test y refactorizar
31. BDD a grandes rasgos
• usar lenguaje de dominio, no técnico
• escribir tests de aceptación con los clientes
(expertos de dominio)
• ciclo de desarrollo usando un doble anillo RGR
32. doble anillo
de BDD
1. se empieza con un ciclo RGR de un test de aceptación
(Anillo Exterior)
2. se va desarrollando hasta que el mensaje de error ya
no nos es útil para seguir (outside in)
3. se baja a hacer un test unitario y se continúa con ese
ciclo RGR (Anillo Interior)
4. anillo Interior refactorizado: se sube al Anillo Exterior
5. repetir 2-4 hasta que el Anillo Exterior esté completado
34. qué se consigue
con BDD
• mejor comunicación con clientes y stakeholders
• menos frágil: tests de aceptación y
sólo los unitarios necesarios
• más natural y rápido
35. limitaciones
de BDD
• sólo probamos el caso feliz
• cuando el test es muy difícil de programar
• cuando se tiene muy claro
• cuando los tests unitarios se rompen
• cuando no se tiene ni idea de por dónde tirar
39. tests unitarios extra
• tras un ciclo RGR y antes del siguiente
• ¿cómo debería comportarse el sistema ante esta
situación?
• es diseño
• ok si el test empieza en Verde lugar de Rojo.
48. REPL
• Read Eval Print Loop
• consola de javascript, irb/pry…
• ir ejecutando lo que se programa en el momento
• muy bueno para pruebas, bugfixing,
y para “¿cómo se usaba esto?”
• REPL Driven Development
52. mi proceso al principio
• diseño y desarrollo tradicional
• pruebas al final (bastante escasas),
apoyado por un buen equipo de QA
53. mi proceso ahora
• por defecto:
BDD con Outside-In
• “¿cómo era esto?” y “¿cómo se usaba tal?”:
REPLs!
• “ni idea” o “peligroso”:
Spikes!
• “trillado”:
Pasos largos!
• “test difícil”:
Prueba manual
54. ¿qué he ganado?
• muchos menos errores
• más constante
• más seguro
• más rápido