El documento explora diversas metodologías de desarrollo de software, criticando enfoques tradicionales y defendiendo el uso de pruebas automatizadas, TDD (desarrollo guiado por pruebas) y BDD (desarrollo guiado por comportamiento). Se destacan las ventajas de estas técnicas, como mayor velocidad, menor cantidad de errores y mejor comunicación con los clientes. Además, se presentan métodos para superar las limitaciones de estos enfoques y se concluye que la combinación de diferentes técnicas es clave para mejorar el desarrollo de software.

1. Demystifying
Development Techniques
@eturino
Eduardo Turiño

2. ¡muerte a los puristas!
el “otro título”

3. las metodologías son
sólo herramientas

4. menos errores
más velocidad
más constancia

5. mejorar en cada paso
lo que más moleste

6. •
nivel de Proyecto (Scrum, Kanban…)
•
nivel de Desarrollo!
•
nivel de Productividad (GTD, Pomodoro…)

7. el camino
1
2
3
4
5
6
1. tradicional
4. TDD
2. tests automáticos
5. BDD
3. Test-First
6. completando BDD

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

9. 1
2
3
4
5
tradicional
¿cómo se hace normalmente?
6

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)

13. 1
2
3
4
5
tests automáticos
automatizando las pruebas manuales
6

14. tipos de tests
de Aceptación:
comprueba funcionalidad
de Regresión:
nos alerta si hemos roto algo anterior
Unitarios:
componente (aislado) funciona bien

15. cuidado
sustituyen a pruebas manuales:
probar comportamiento

16. lo que más molesta
de los tests automáticos
•
poca motivación para hacerlos
•
“¿y cómo pruebo yo esto?”

17. 1
2
3
4
5
6
Test-First
probando lo que aún no hemos desarrollado

18. primero el test
!
después el código de producción

19. ventajas
de Test-First
•
mayor motivación
•
sensación de seguridad: menos fallos tontos
•
código más sencillo y fácil de probar

20. lo que se echa en falta
de Test-First
no nos sirve de guía

21. 1
2
3
4
5
TDD
Test Driven Development
6

22. los tests como
guía del desarrollo

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

25. Red - Green - Refactor
Green
Red
Refactor

26. Red - Green - Refactor
Green
⇧ funcionalidad
⇧ diseño
Red
Refactor
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

28. temas a mejorar
de TDD
frágil y tedioso
muchos test unitarios

29. 1
2
3
4
BDD
Behaviour Driven Development
!
o TDD “bien hecho”
5
6

30. comportamiento,
comunicación,
y tests de aceptación

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

33. doble anillo
R
R
Aceptación
G
Unitario
Rf
Rf
G

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

36. ¿y ahora?

37. completamos con
otras técnicas

38. 1
2
3
4
5
6
solucionando
“probar sólo el caso feliz”

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.

40. 1
2
3
4
5
6
solucionando
“test difícil de programar”

41. solucionando
“test muy difícil”
sustituye por
prueba manual

42. 1
2
3
4
5
solucionando
“cuando es muy fácil”
6

43. solucionando
“cuando es muy fácil”
pasos largos

44. 1
2
3
4
5
solucionando
“tests se rompen”
6

45. solucionando
“tests se rompen”
arreglarlos o tirarlos

46. 1
2
3
4
5
6
solucionando
“cuando es muy difícil”

47. solucionando
“cuando es muy difícil”
REPLs y Spikes

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

49. Spike
experimento rápido para:
A. disminuir riesgo técnico
B. pruebas de concepto

50. Spike
cuando se termina:
•
si es muy horrible:
se tira
•
si se puede refactorizar y “no está tan mal”:
se usa y se le añade un test de regresión

51. concluyendo…

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

55. buscando
las mejores herramientas
para cada ocasión

56. el objetivo es el software
!
complementar tu metodología
con otras técnicas
está bien