viernes, agosto 25, 2006

Luego de la Charlar de TDD

Ayer, finalmente, dí la charla de TDD, muchas gracias por los comentarios, me sirvieron mucho. Creo que salio bastante bien, o al menos yo me sentí coforme y tuve buen feedback, quedó grabada, si en algun momento puedo ripearla a algún formato "reproducible" fuera de IBM lo voy a hacer.
En los temas que mas me focalicé que muchas charlar olvidan discutir:
- El origen del TDD y los problemas actuales
- Que ventajas tiene el TDD
- Y los problemas y como manejarlos que puede traer implementarlo en un proyecto (mas allá de usar o no XP)
Dejo las ventajas y los problemas para discutir:
Ventajas:
  • Tests determine what code you need to write
  • Constant Regression Testing
  • Improved Communication
  • Improved Software Design
  • Tests are well completion criteria
  • Facilitate software changes
  • Remove / Reduce reliance on the debugger
  • Reduced defects
Problemas a la hora de implementarlo (la mayoria fueron sacados del ibro Paragmatic Unit Testing):
  • It takes too much time to write the tests
  • It takes too long to run the tests
  • It's not my job to test my codeI don't really know how the code is supposed to behave so I can't test it
  • But it compiles!
    I'm being paid to write code, not to write tests
  • I feel guilty about putting testers and QA staff out of work
  • My company won't let me run unit tests on the live system
  • Dependency is complex to handle
Todos estos problemas obviamente pueden ser solucionados, eso lo explique en la charla.
Si encuentran alguno más para compartir bienvenido sea.

2 comentarios:

mapariblo dijo...

Me parece interesante tambien:

- No dejar pasar un check-in sino pasa el build y los tests. Build lo mas estable posible.

- Tener reportes de que porcentaje del codigo esta cubierto por los tests. Que porcentaje es aceptable?

- No escribir tests que sean mas dificiles que el codigo testeado. O que haya que hacer un test del test! :)

Pablo

Gustavo Andrés Brey dijo...

Recien acabo de leer el comment (mil disculpas!!!) Respondo:
- No dejar pasar un check-in sino pasa el build y los tests. Build lo mas estable posible.

Importanticimo, aunque pueda llegar a traer algunos problemas de performance dependiendo de la cantidad de test que estas corriendo, creo que se deberían limitar al módulo en el que estás trabajando.

- Tener reportes de que porcentaje del codigo esta cubierto por los tests. Que porcentaje es aceptable?
Que lindo tema!!! Aunque no creo que haya un % que sirva para todos los proyectos, lamentablemente los test coverage es un arma de doble filo y si se implementa como una métrica puede traer complicaciones... yo me animaría a utilizar el reporte de cobertura para medir el pogreso de la construcción :)


- No escribir tests que sean mas dificiles que el codigo testeado. O que haya que hacer un test del test! :)

Está claro, y es un punto importantísimos, cuando escribís un test case muy complejo quiere decir que no está bien tu diseño y hay que cambiarlo para tender a algo simple. Últimamente me estoy metiendo en ver como hacer los test cases más expresivos y no tan javachototipadollenodefeosasserts, y es por eso que me gusta mucho el tema de BDD y los nuevos utilitarios para hacer asserts más entendibles.