jueves, octubre 07, 2010

Permiso para hacer TDD

Al estar en platicas/presentaciones sobre TDD (Test Driven Development) donde los participantes son gente que ya esta trabajando. La mayoría de los participantes coincide en que es una buena practica realizar el desarrollo guiado por pruebas. Sin embargo una pregunta que surge frecuentemente es ¿Como convenzo a mi jefe de hacer TDD?

Bueno para empezar no creo que un equipo de desarrollo deba pedir permiso para escribir mejor código, debería ser su obligación. Todos deberíamos de tratar de realizar cada vez un mejor trabajo. Mientras se entreguen resultados con calidad no debería de haber problema con los jefes.

Es claro que el realizar pruebas unitarias aumenta la cantidad de código escrito. Pero solo es eso, mas código y de mejor calidad. Si bien es cierto que eso implica mas tiempo (al principio), también es cierto que el tiempo invertido en el código de una prueba es menor al tiempo que se invierte en mantener el código después o en encontrar un bug que una prueba (y un mejor diseño) nos hubiera evitado. Al final estamos escribiendo mejor código que prácticamente ya esta probado. Y al realizar TDD frecuentemente el tiempo para realizar prueba e implementación mejora.

Entonces al realizar TDD pasa lo siguiente:

  1. Mejora el diseño
  2. Mejora el código, es mas fácil modificarlo después
  3. Aumenta el numero de clases (código)

Ahora yo te pregunto ¿Necesitas convencer a tu jefe de que te deje escribir una clase?

Creo que la respuesta es no; así que solo hazlo. Escribe tus pruebas unitarias sin hacer una junta con tu jefe. Hazlo como parte del desarrollo normal del proyecto. Pero, si la respuesta es sí, es decir que necesitas convencer a tu jefe que te deje escribir una clase o un archivo con código entonces quizás tengas un problema mas grande.

Si tu estas convencido que es lo mejor, no esperes a convencer a otros para sentir que tienes la razón. Solo haz lo mejor.

1 comentario:

  1. Hola,

    Yo no soy fan de TDD en su totalidad, o sea no estoy de acuerdo con la receta completa, pero como lider de proyecto debo asegurarme que mi producto venga con los menores errores posibles, por lo que es mi tarea (y no la del programador) justificar el tiempo invertido en test a la directiva, la responsabilidad del programador no es solo entregar codigo que satisfaga las necesidades pero tambien que cubra escenarios no previstos.

    La forma en la que aplico TDD en mi equipo es hacer que los tests sean escritos por programadores ajenos al source code. Ademas de no dejar que los UnitTest sean los garantizadores de la funcionalidad total del producto, pero eso es harina de otro costal.

    Saludos

    ResponderEliminar