En esta charla os voy contar los pasos que he dado para poco a poco ir incorporando la práctica de TDD a mi día a día (desde las trincheras). Os contaré las cosas que me han funcionado y las que no. Y también veremos cómo algunas otras prácticas (testing, refactoring y clean code) me han ayudado a entender y poder abrazar de mejor manera el uso de TDD.
5. Excusas
● Superiores (jefes de proyecto, gerentes, etc) que
no permiten el uso de TDD
● Proyectos legacy y código muy difícil de mantener
● Plazos de proyecto muy cortos. Sin tiempo de
practicar TDD
6. Superiores que no permiten el uso
de TDD
● ¿Hay que pedir permiso para pensar?
● ¿Pedimos permiso para practicar o para
aprender?
7. Proyectos legacy
● No hay nada que te impida desarrollar nueva
funcionalidad usando TDD
● Aunque... puedes necesitar dependencias
del proyecto que te dificulten los tests
8. Plazos de proyecto muy cortos
● Cuando programo dedico más tiempo a pensar
que a escribir código
● Trabajar a destajo puede dar la sensación de
más velocidad pero luego se paga más caro
● La velocidad debe ser una consecuencia de
hacerlo bien, no una aptitud
20. Katas
● Lo importante de una kata es aprender, no terminarla
● Cuando ves que has llegado a un callejón sin salida, no
tengas miedo a borrar código y empezar de cero (o
pasos anteriores)
● Compara tus soluciones con las de otros:
– https://github.com/12meses12katas
– http://codingdojo.org
– http://www.solveet.com
22. Practica en el trabajo
● Antes de probar algo nuevo, tienes que
conocer el sistema
● Busca partes del proyecto donde te
encuentres cómodo
● Practica de forma progresiva
23. Metódico/Constante
● Lista de ejemplo antes de hacer el primer test
● Pon atención a los tres etapas: red, green y
blue. Las tres son importantes
● Baby steps. Escribir el código mínimo para
pasar los tests
● Los tests también se tienen que mantener. En
la fase de refactor hay que revisarlos
● Keep It Simple. Less astonishment principle
● Usa buenos nombre
24. Aún así, me atasco practicando TDD
● The Transformation Priority Premise
https://8thlight.com/blog/uncle-
bob/2013/05/27/TheTransformationPriorityPr
emise.html
● Why do you get stuck? Because you were
not adding sufficient generality to the
production code
http://blog.cleancoder.com/uncle-
bob/2014/12/17/TheCyclesOfTDD.html
25. Bugs (nuevo mindset)
● Antes de corregir el bug, añade un test
que demuestre que falla
● A continuación, resuelve el bug y certifica
que el test está en verde
● La regla del Boy Scout
26. Four rules of simple design
● Passes the tests
● Reveals intention
● No duplication
● Fewest elemens