1. GERARDO BARCIA PALACIOS
www.gerardobarcia.com
@gerardobarciap

2. 4 Julio, 1996

3. overflow 37 segundos después del despegue del ARIA

4. Con consecuencias
gravísimas…

6. La falla se produce cuando un float
se convierte a entero corto

7. $370 se perdieron

8. Esta excepción no podría ocurrir en su antecesor el Ariane 4, por
lo que la reutilización de componentes se hizo sin pruebas del
sistema a fondo, pues era caro. ¡FUE AÚN MÁS CARO!

9. “Los desastres causados por el software son
muy famosos. Por el Hardware, son difíciles de
encontrar.”

10. – Gerald Weinberg, Weinberg’s Second Law
“Si los constructures construyesen los edificios
de la misma forma en que los programadores
escriben los programas, el primer pájaro
carpintero que llegase destruiría la civilización”

14. Motivación de la charla

15. ¿Qué ha pasado?
David Heinemeier Hansson
(DHH) comenzó a expresar su
descontento con TDD y los
UnitTest en la comunidad de
Rails.
Kent Beck y Martin Fowler
(defensores de TDD) se han
unido al debate.

16. ¿TDD COMO PROBLEMA?

17. ¿De qué conversaremos?
TDD
DHH
BECK Y
FOWLER
Sandi
Metz

18. Dos Conceptos

20. Arquitectura Hexagonal

21. Técnica 1: Usar casos de Servicios

22. Técnica 2: Controladores Pasivos

23. Técnica 3: Uso de repositorios

24. ¿Qué plantea DHH?
Ingeniero de Software VS Escritor de
Software

25. LAS PRUEBAS
PRIMERO
¿Es fundamentalismo?¿Cuál
es su límite?
TDD

26. Impacto en el
diseño
- ¿Hacer código más
testeable?
- Arquitecturas viciadas y
código ilegible

29. COSTO != VALOR

30. Mejorar el diseño de nuestras apps
leyendo, no solo con TESTS

31. ¿De qué conversaremos?
TDD
DHH
BECK Y
FOWLER
Sandi
Metz

32. – Kent Beck
“Escribir las pruebas primero es solo uno de
los caminos para hacer código de calidad”

33. ¿La culpa de llegar a un mal lugar es del coche?

34. El viejo dilema de
Acoplamiento y Cohesión

37. Beck y Fowler plantean que el
problema es de diseño, no de TDD

38. ¿De qué conversaremos?
TDD
DHH
BECK Y
FOWLER
Sandi
Metz

39. Conoce tus intenciones
Conoce que Probar
Conoce cuando Probar
Conoce como probar
PRINCIPIOS

40. Enfocarse en los mensajes
Pensar en los objetos como simples conectores
TÉCNICAS

47. la idea central es realizar test cuando sea
necesario y los necesarios. TDD es recomendable.
no obligatorio.

48. REFLEXIONES

49. ES SANO CUESTIONAR

50. Contexto
Generalizar es
equivocarse siempre

51. Los extremos pueden ser
buenos

52. Ha comenzado una carrera por
salvar al agilizo de los agilitas
#TDDisDead
#NoEstimate

53. fin?

54. ELIGE TUS BATALLAS

55. http://martinfowler.com/articles/is-tdd-dead/
Ampliar la información

57. GERARDO BARCIA PALACIOS
www.gerardobarcia.com
@gerardobarciap