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
- 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
Si encuentran alguno más para compartir bienvenido sea.
2 comentarios:
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
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.
Publicar un comentario