$30 off During Our Annual Pro Sale. View Details »

Introducción a TDD (Agile Coruña)

Introducción a TDD (Agile Coruña)

Charla y posterior kata de introducción a TDD impartida por Borja (https://twitter.com/borjal) y yo.

Isidro López

January 16, 2018
Tweet

More Decks by Isidro López

Other Decks in Programming

Transcript

  1. Introducción a TDD A Coruña, 16 de enero de 2018

    Borja Fdez Pillado (@BorjaL) Isidro López (@islomar)
  2. Ego slide Desarrollador de software (de sabático) @islomar [email protected] Desarrollador

    de software (Barkibu) @borjal https://borjafernandezpillado.com
  3. ¿Para qué estamos aquí? • Para divertirnos, aprender y compartir

    • Qué son los tests automatizados • Qué es TDD (Test-Driven Development) • Qué es una kata • Trabajar en parejas y con pomodoros
  4. ¿Qué es un Coding Dojo? • Lugar donde aprender, mejorar

    y divertirse programando • Lugar donde experimentar • Lugar seguro para practicar: diseño, testing, refactoring, herramientas, etc. • En parejas: humildad, generosidad, agradecimiento • Práctica deliberada • NO es un curso ni una formación ni una “clase maestra”: facilitadores
  5. Disclaimer Shu-Ha-Ri: si nos “creéis”, hacedlo poco... y sólo de

    momento Probad y verificad siempre todo por vuestra cuenta
  6. Tests automatizados • Red de seguridad = Tranquilidad • Automatizar

    = Ahorro de tiempo • Documentación • Demuestran la presencia de errores, no su ausencia • ¿Testear todo? Imposible y no deseable • QA como rol, no como departamento
  7. calculadora = MiCalculadora() # Arrange resultado = calculadora.suma(2, 2) #

    Act expect(resultado).to(equal(4)) # Assert Estructura de un test: AAA http://wiki.c2.com/?ArrangeActAssert
  8. ¿Cuándo ejecuto los tests? • Integrado en el IDE/editor/entorno: ante

    un cambio, se reejecutan • Cada commit/push al repo: hooks o https://github.com/typicode/husky • Integración continua o Despliegue Continuo (Continuous Deployment) ◦ Idealmente: entorno idéntico de tests y producción (e.g. con Docker) ◦ Ejemplo: https://github.com/islomar/url-shortener-islomar • Tareas configuradas vía Webpack, Gulp, Grunt, Gradle, Maven, etc.
  9. Apreciaciones varias • Código de test: ciudadano de primera, como

    el de producción • Idealmente un único assert por test
  10. ¿Qué es TDD? TL; DR: escribir el test antes que

    el código de producción. Una vez que tengas el test funcionando, puedes refactorizar. TDD es una técnica de desarrollo de software, una disciplina
  11. ¿Qué NO es TDD? TDD NO es simplemente una forma

    de escribir tests TDD NO es una técnica de diseño ni necesariamente mejora tu diseño
  12. Qué aporta TDD (I) • FOCO en la funcionalidad a

    desarrollar: escribir menos código • Feedback rápido • Simplicidad • Cadencia, flow…
  13. Qué aporta TDD (II) • Descubrir poco a poco cómo

    resolver el problema • Crear mejores tests de tu código • Documentación (muy probablemente mejor) • Mejor diseño (si ya tienes los conocimientos) https://www.codesai.com/2016/10/lo-que-me-aporta-tdd
  14. ¿Cuándo no haría TDD? • Spikes ◦ Muy alta incertidumbre,

    exploración de una posible solución: tras verificar, borrarlo y empezar con TDD • Código MUY legacy (sin tests, pésima legibilidad, etc.) • Otros: e.g. un script simplón que voy a ejecutar una única vez, no crítico
  15. ¿Y todo esto, pa’ qué? • Para vivir más tranquilos

    • Para disfrutar más de tu trabajo (e incluso querer ir :-) ) • … y para servir a negocio (aka aportar valor): clientes más satisfechos, menor Time-To-Market, más beneficios, etc. • Es NUESTRA responsabilidad (no “just following orders”)
  16. Kata FizzBuzz Cómo vamos a hacerlo: • Pomodoro (introducción +

    3 iteraciones de 25 minutos cada una) • Pair programming + Ping Pong • Escribe lo mínimo para que funcione y pase el test https://github.com/CraftersEntrePercebes/FizzBuzz
  17. Bonus track • Devolver “Woof” si un número es divisible

    por 7 • Devolver “Fizz” si es divisible por 3 o si incluye un 3 en el número • Devolver “Buzz” si es divisible por 5 o si incluye un 5 en el número • Un único nivel de indentación por método • Sin condicionales (if, while, etc.) • Sin bucles (for, while, foreach, etc.) • No más de 4 líneas por método.
  18. Resumiendo, que es gerundio • Testing: imprescindible… casi siempre •

    TDD: técnica de desarrollo, más que recomendable • Prueba y juzga por ti mismo • Rodéate de buena gente con experiencia (y busca una mentora/mentor) • A nivel profesional, el software es un medio para un fin: ¡nunca lo olvides!
  19. Bibliografía • TDD by example (Kent Beck) • Growing Object-Oriented

    guided by tests (Steve Freeman, Nat Pryce) • Diseño ágil con TDD (Carlos Blé) • Specification by example (Gojko Adzic) • Refactoring (Martin Fowler) • Clean Code (Uncle Bob) • XP Explained (Kent Beck)
  20. Screencasts • Screencasts de Sandro Mancuso: ◦ Algorithms: https://www.youtube.com/watch?v=iZjgj1S0FCY ◦

    Outside-In TDD: ▪ https://www.youtube.com/watch?v=XHnuMjah6ps ▪ https://www.youtube.com/watch?v=24vzFAvOzo0 • Carlos Blé ◦ Implementando algoritmos con TDD ◦ Kata sobre juego de cartas
  21. Charlas • Joaquín Engelmo (@kinisoftware) ◦ Adicto al verde ◦

    Dando amor a los tests • The limited red society • The three laws of TDD • Test-Bridle Development (@flipper83), SCPNA
  22. Artículos y webs de interés • https://martinfowler.com/bliki/IntegrationTest.html • https://martinfowler.com/articles/microservice-testing/ •

    http://www.agiledata.org/essays/tdd.html • https://medium.com/@ramtop/what-im-talking-about-when-i-talk-about-t dd-546a383468be • https://medium.com/powtoon-engineering/a-complete-guide-to-testing-ja vascript-in-2017-a217b4cd5a2a • Ideas para katas: https://github.com/12meses12katas