Charla sobre Test Driven Development en la Universidad Jaume I de Castellón en Marzo de 2010

1. Desarrollo Dirigido por Ejemplos Concretar en lugar de Abstraer Carlos Blé Jurado Marzo 2010 – Universitat Jaume I www.carlosble.com

2. Nada más salir de la facultad... “ ¡Podemos programar lo que sea!!” “ ¡Despues de la carrera saco adelante cualquier cosa!!!!!!”

3. Y va la experiencia y dice... “ así que... podeis hacer lo que sea...” “ ¡y quien lo va a mantener !!!!!! ”

4. No te tortures con código imposible ni se lo hagas a tus compañeros No juegues con el dinero del cliente. Dale soluciones, no más problemas Tranquilo majete: haz las cosas bien

6. ¡¡¡¡¡¡¡ AL REVES !!!!!!!! A lo mejor es que los estamos haciendo...

8. No hace lo que el cliente necesita que haga (hace otros rollitos que están que te cagas y tal)

9. Es muy caro de mantener y (más vale que el cliente evolucionar no pida cambios)

11. Transcribir (volcar los requisitos en 500 páginas)

12. Abstraer (intentar resumir las 500 páginas en conceptos)

13. Modelar (diagramas de clases, etc)

14. Implementar (a picar código)

15. Probar (tres días usando la app a mano)

16. Entregar (cobrar y salir pitando)

19. Transcribir (escribimos historias de usuario)

20. Concretar (escribir criterios/tests de aceptación)

21. Probar/Implementar (primero la prueba, ¡cobarde!)

22. Entregar (una entrega cada 3 semanas y volver al inicio)

23. La rueda ágil

24. Concretando: TDD

25. ATDD + TDD

27. Los ejemplos son el puente que une a técnicos y usuarios/clientes

29. Ejemplo de ejemplo :-) 40x20+8x20x1.5+8x20x2 Ejemplo de ejemplo :-)

31. Ahora vamos a pensar cómo queremos diseñar e implementar el software

32. Y vamos a implementarlo Escribimos un test (JUnit, NUnit, PyUnit...) Lo hacemos funcionar lo antes posible (implementamos el código de producción) Refactorizamos el código

33. Un test unitario

34. Cada cosa tiene su ámbito ATDD – ¿Qué quiere el cliente? TDD – ¿Cómo lo implementamos?

36. No se implementa lo que no será usado (YAGNI)

37. Minimizamos el número de defectos

38. Conseguimos código más fácil de mantener

39. Código preparado para cambiar

40. Aumenta la confianza del equipo

41. Aumenta la productividad

42. Detectamos antes las prioridades del cliente

43. ¿Cómo aprender todo esto? Hay un tipo por ahí que imparte cursos Hay un libro en castellano sobre el tema Hay una comunidad de habla hispana Hay toneladas de herramientas libres ¿Tienes ganas? Just do it!!!

44. dirigido Por Tests .com Agile-spain.com carlosble.com Tambien estamos en Facebook!: