Escribo mi c\u00f3digo con TDD casi desde\u00a0mis inicios\u00a0como desarrollador\u00a0de software, y a lo largo del tiempo he visto los beneficios de hacerlo, y las consecuencias de no hacerlo. Quer\u00eda compartir mi vivencia acerca de este tema.<\/p>\n
\u00abCon TDD no voy a tener m\u00e1s bugs\u00bb \u00a0<\/em><\/p>\n Falso<\/strong>. TDD garantiza que el c\u00f3digo va a funcionar en la manera esperada, en los casos en los que fue pensado. No va a evitar que me olvide de considerar alg\u00fan caso, o que entienda mal un requerimiento.<\/p>\n <\/p>\n \u00abDesarrollar con\u00a0TDD es lento\u00bb<\/em><\/p>\n Falso<\/strong>. El desarrollo de software no solamente consiste en escribir el c\u00f3digo de una funcionalidad X en un determinado momento. Tambi\u00e9n es garantizar que el resto de las funcionalidades siguen andando correctamente , y es mantener y hacer crecer el c\u00f3digo a lo largo del tiempo. Cada vez que tenemos m\u00e1s funcionalidades desarrolladas (y por ende m\u00e1s c\u00f3digo), es exponencialmente m\u00e1s dif\u00edcil garantizar que todo ande como debe. El hecho de tener tests unitarios y\/o componentes nos ayuda a saber que rompimos algo de inmediato. Los beneficios de TDD puede que no se noten al principio del proyecto, pero a medida que va avanzando, cada vez da m\u00e1s valor.<\/p>\n <\/p>\n \u00abTDD ayuda a documentar el c\u00f3digo\u00bb<\/em><\/p>\n Verdadero<\/strong>. Los tests unitarios nos dicen qu\u00e9 escenarios fueron considerados al momento de escribir el software, y c\u00f3mo debe responder ante cada uno de esos escenarios. Seguramente sea la documentaci\u00f3n m\u00e1s actualizada que tengamos del software, ya que los estamos manteniendo constantemente.<\/p>\n <\/p>\n \u00abSi hago TDD, no necesito tener un Tester en el equipo\u00bb<\/em><\/p>\n Falso<\/strong>. Los tests automatizados no reemplazan la experiencia de un tester a la hora de probar casos \u00abraros\u00bb que no se le ocurrieron al desarrollador al momento de dise\u00f1ar y escribir el software. El tester o QA deber\u00eda hacer pruebas exploratorias, del tipo de \u00ab\u00bfQu\u00e9 pasa si hago esto…?<\/p>\n <\/p>\n \u00abCon TDD es m\u00e1s f\u00e1cil arreglar un bug\u00bb<\/em><\/p>\n Verdadero<\/strong>. Una vez que el QA (o si somos menos afortunados, un usuario) encuentra un bug, tenemos que analizar cu\u00e1l es el escenario o la combinaci\u00f3n de datos que lo provocan, y escribir un test que reproduzca dicho escenario. Una vez que tengamos el test, podremos dedicarnos a arreglar el c\u00f3digo productivo, teniendo la certeza de que realmente lo estamos arreglando sin romper otra cosa, gracias al resto de la bateria de tests.<\/p>\n <\/p>\n \u00abCon TDD el c\u00f3digo queda m\u00e1s limpio\u00bb<\/p>\n Verdadero<\/strong>. Nos obligamos a escribir el m\u00ednimo c\u00f3digo que hace pasar los tests, sin enredarnos en validaciones \u00abpor las dudas\u00bb. Adem\u00e1s, el test nos obliga a pensar en los m\u00e9todos que expondremos, qu\u00e9 recibir\u00e1n y qu\u00e9 retornar\u00e1n, es decir que nos ponen un poco del lado del cliente de nuestrasAPIs. Recuerden: si es dif\u00edcil de escribir un test para el c\u00f3digo, entonces tenemos que revisar el dise\u00f1o.<\/p>\n <\/p>\n \u00abYo tengo experiencia desarrollando, no necesito hacer TDD\u00bb<\/em><\/p>\n