TDD
desde las trincheras
Juan Lladó
@jllado
Travel Compositor
http://online.travelcompositor.com
Motivación de la charla
Motivación de la charla
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
Superiores que no permiten el uso
de TDD
● ¿Hay que pedir permiso para pensar?
● ¿Pedimos permiso para practicar o para
aprender?
Proyectos legacy
● No hay nada que te impida desarrollar nueva
funcionalidad usando TDD
● Aunque... puedes necesitar dependencias
del proyecto que te dificulten los tests
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
Disclaimer
eXtreme Programming
XP: valores
● Simplicidad
● Comunicación
● Retroalminetanción
● Coraje
● Respeto
TDD
TDD
http://blog.jbrains.ca/
Escuelas de TDD
● Classical/Inside-Out (Chicago)
● Mockist/Outside-In (London)
– Doble de test:
http://www.martinfowler.com/bliki/TestDouble.html
¡Quiero práctiar TDD!
Valora tus conocimientos
● Testing
● Patrones y principios de diseño
● Refactoring/Herramientas de trabajo
¡Lee!
● Clean Code (Robert C. Martin)
● TDD by Example (Kent Beck)
● Effective Unit Testing (Lasse Koskela)
● Growing Object-Oriented Software, Guided by
Tests (Steve Freeman y Nat Pryce)
● Diseño Ágil con TDD (Carlos Blé)
Screencasts
● Kata de las Cartas (Carlos Blé)
https://www.youtube.com/watch?v=LJQnxDZQHoo
● Testing and Refactoring Legacy Code (Sandro Mancuso)
https://www.youtube.com/watch?v=_NnElPO5BU0
● Outside-In TDD (Sando Mancuso)
https://www.youtube.com/watch?v=XHnuMjah6ps
¡Practica!
Encontrar situaciones cómodas donde
poder practicar sin presión
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
Katas
http://www.slideshare.net/PedroSantos205/software-craftmanship-coaching
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
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
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
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
Four rules of simple design
● Passes the tests
● Reveals intention
● No duplication
● Fewest elemens
SOLID
● Single responsibility principle
● Open/closed principle
● Liskov substitution principle
● Interface segregation principle
● Dependency inversion principle
¡No pares de aprender!
¿Preocupado por la velocidad?
¿Preguntas?
¡GRACIAS!
Juan Lladó
@jllado

Tdd desde las_trincheras

  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
    Excusas ● Superiores (jefesde 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 nopermiten el uso de TDD ● ¿Hay que pedir permiso para pensar? ● ¿Pedimos permiso para practicar o para aprender?
  • 7.
    Proyectos legacy ● Nohay nada que te impida desarrollar nueva funcionalidad usando TDD ● Aunque... puedes necesitar dependencias del proyecto que te dificulten los tests
  • 8.
    Plazos de proyectomuy 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
  • 9.
  • 10.
  • 11.
    XP: valores ● Simplicidad ●Comunicación ● Retroalminetanción ● Coraje ● Respeto
  • 12.
  • 13.
  • 14.
    Escuelas de TDD ●Classical/Inside-Out (Chicago) ● Mockist/Outside-In (London) – Doble de test: http://www.martinfowler.com/bliki/TestDouble.html
  • 15.
  • 16.
    Valora tus conocimientos ●Testing ● Patrones y principios de diseño ● Refactoring/Herramientas de trabajo
  • 17.
    ¡Lee! ● Clean Code(Robert C. Martin) ● TDD by Example (Kent Beck) ● Effective Unit Testing (Lasse Koskela) ● Growing Object-Oriented Software, Guided by Tests (Steve Freeman y Nat Pryce) ● Diseño Ágil con TDD (Carlos Blé)
  • 18.
    Screencasts ● Kata delas Cartas (Carlos Blé) https://www.youtube.com/watch?v=LJQnxDZQHoo ● Testing and Refactoring Legacy Code (Sandro Mancuso) https://www.youtube.com/watch?v=_NnElPO5BU0 ● Outside-In TDD (Sando Mancuso) https://www.youtube.com/watch?v=XHnuMjah6ps
  • 19.
    ¡Practica! Encontrar situaciones cómodasdonde poder practicar sin presión
  • 20.
    Katas ● Lo importantede 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
  • 21.
  • 22.
    Practica en eltrabajo ● 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 deejemplo 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í, meatasco 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 ofsimple design ● Passes the tests ● Reveals intention ● No duplication ● Fewest elemens
  • 27.
    SOLID ● Single responsibilityprinciple ● Open/closed principle ● Liskov substitution principle ● Interface segregation principle ● Dependency inversion principle
  • 28.
    ¡No pares deaprender!
  • 29.
  • 30.
  • 31.