Mi Opinión y Experiencia Personal sobre TDD – y de por que NO estoy MUY de acuerdo con el –

Estoy últimos días e visto platicas, post ( uno de ellos es este )   y mensajes en el twitter sobre cuestiones “agiles”  y temas afines, aunque un tema en particular atrajo mi atención, es sobre TDD o  como algunos lo conocen, y ya no pude evitar querer dar mi opinión al respecto; aunque antes que nada me veo obligado a dar unas premisas, en las cuales basare mi “punto”

Premisas ( o como las quieran llamar)  :

  1. No todos los Programadores tienen el mismo Nivel : Esto es conocido por todos, aunque no aceptado públicamente – cuestiones de orgullo –,  así como hay programadores que no necesitan documentación – un amante de gnu por allí de ejemplo? –, y otros que no necesitan pruebas unitarias para hacer programas con cero errores o quizá un numero mínimo de ellos… así también hay programadores, que con toda la documentación, capacitación y pruebas unitarias les falla la aplicación.. causas?  quizá algún gen maligno, magia negra, el chupa cabras, la CIA interfiriendo nuestras ondas cerebrales con algún aparato electrónico a lo “Agente 86”… o quizá algo mas de experiencia y aprender de los errores pasados sumado un poquito de mucho estudio y practica.
  2. Que exista cierta metodología o proceso, implica que hay personas a las que SI les funciono, pero no significa que a todos les funcionara. que exista RUP, SCRUM, etc. significa que hay personas a las que siguiendo los pasos que le fueron indicados, tuvieron éxito en lo que buscaban, pero esto a su vez no implica que a todos les ira bien, posibles factores son muchos –
  3. Las Metodologías, técnicas, etc., no son Leyes : aunque suene feo, si obviamos usar determinada metodología “así tal cual viene en la caja”, si evitamos usar rup, scrum, etc etc etc.. esto no implica que nuestro software tenga muchos errores, o no sea optimo, las metodologías solo son una guía en la cual nos podemos basar para intentar tener un buen resultado con un mínimo costo / tiempo, OJO no estoy impulsando a no usarlas, solo quiero aclarar que no es un pecado capital “el no usarlas”, lógicamente que es como el juego de la ruleta rusa, nos puede ir bien  o nos puede ir mal, personalmente no soy de los que usa algo “tal cual viene en la caja” sino que lo personalizo hasta poder sacar el máximo rendimiento.
  4. Un Programador no piensa igual que alguien involucrado a fondo en el área de pruebas – a menos que tenga extrema experiencia en el tema-  :  en este punto e tenido algunas discusiones – muy placenteras – con algunos colegas; tengo algunos años – no muchos  si los comparo con algunos de los maestros que rondan por aquí en geeks.ms – e trabajado junto  a desarrolladores de al menos 2 países ( Perú y México) y con mas de 6 años de experiencia en pruebas, y e podido constatar – eso sin tomar en cuenta a lo que ya dicen muchos  respecto al tema –, que la forma de pensar de un programador “promedio” – ojo con la premisa 1 –  su forma de ver las cosas es como “construir” algo, su mente este abocada a armar software y es muy difícil – por no decir casi imposible – en pensar a fondo en pruebas, lógicamente se le ocurrirá una que otra, de cosas simples o básicas, pero no de las que son a profundidad;  a diferencia de alguien involucrado en pruebas – y no me refiero a los pica botones – en el cual su mente esta abocada a “Destruir” y pensar en como destrozar algo que otro realizo, se que muchos me dirán que no es cierto, pero e realizado la prueba con muchos programadores -soy del tipo que le gusta hacer experimentos son la gente- y los resultados fueron muy claros. Lógicamente hay personas con algo de experiencia – y que no tienen perdida de memoria –  y con el transcurrir el tiempo van pensando en pruebas cada vez mas complejas, lamentablemente este ultimo grupo es muy reducido. – no me extiendo mas, sino me auto robo el tema del siguiente post, que espero sacarlo ahora si –
  5. Una prueba unitaria básicamente es: probar que metiendo A datos a X función me devuelva Y; pero esto no implica que si meto B me devolverá Z:  el titulo habla por si solo, me extenderé en esto mas adelante.
  6. Basarse “solamente” en una forma de medir el software  puede ser tu perdición : aquí es simple, el usar “solo X” puede ser la causa que un proyecto se venga abajo, ya que en el software interviene el factor humano, el cual  es capaz de romper cualquier regla, en otras palabras, el hombre esta aplica principio de incertidumbre de Heisenberg, y por lo mismo quizá una forma única de ver las cosas nos diría que estamos en lo correcto, mientras que otra medida nos diría que no. ( al hablar de medidas me refiero a pruebas )

 

Veamos ahora algunos puntos acerca de TDD – por comodidad me fusilare los pasos descritos en wikipedia

  1. Escribir El Requerimiento.
    • Esto es algo que se repite en cualquier metodología/ y forma de trabajar, el error en este punto varia directamente proporcional al que recoge los requerimientos… aunque de aquí depende mucho  el avance del proyecto, sobre que tantos y que tan buenos fueron los requerimientos recogidos –aquí hay material para extenderse otro post –
  2. Escribir las Pruebas.
    • Bueno:
      • El fin aquí es escribir el menor código “funcional” – de la app – al hacer que el programador se dedique a generar código que pase las pruebas,  estas pruebas están basadas en los requerimientos establecidos, aquí el nivel de efectividad depende de la calidad de requerimientos.
      • El echo de escribir la prueba antes que la funcionalidad, nos abre un poco mas la vista sobre que es lo que realmente necesita la aplicación de acuerdo a determinado requerimiento – ya que hay casos en que el error es que simplemente no se entendió bien el requerimiento –.
      • Cuando hay cambios en la aplicación,  se puede correr las pruebas y verificar que la aplicación “aun” supere las pruebas.
      • Las Pruebas unitarias no son el chupa cabras : algo que es absoluto es que Si o SI se tienen que hacer pruebas a la aplicación, ya sea antes o después – como puso Rodrigo en este post , aunque para algunos, escribirlas después hace que ya NO sea TDD-; personalmente las prefiero después.
      • Muchos de los beneficios los integro Ibon Landa en varios links de  este post, que seria bueno que lo vean.
    • Malo:
      • El Echo de que TDD pida que se hagan las pruebas antes, implica que el programador hace tareas de el encargado de pruebas : algo que se puede subsanar dando las pruebas para que lo realice una tercera persona, o se realicen luego de escrita la funcionalidad, lo cual podría traer líos con los puristas de TDD
      • Algunas veces para intentar cubrir todo, se crean requerimientos redundantes, que traen a su vez  pruebas redundantes, lo que implica una perdida de tiempo que se puede entender por perdida de $$.
      • En Algunos casos las pruebas terminan siendo mas complejas que la funcionalidad en si, haciendo que mas que una ayuda, sea un lastre para el proyecto – ojo que no es en todos los casos-
      • Muchas personas – no aplica en todos los casos – consideran que es una perdida de tiempo escribir las pruebas antes que el código, esto también depende de la pericia del programador y a como este acostumbrado a trabajar, personalmente no soy “fan” de escribir las pruebas antes, aunque si me gusta desde la etapa de requerimientos, definir las pruebas que debería pasar la aplicación.
      • que tenga 3000 ( o mas ) pruebas unitarias, no implica que este tomando en cuenta la totalidad de “posibilidades”, ya que una cuestión es probar valores puntuales en funcionalidad puntual  y otra muy diferente  tomar valores y estados en conjunto, ya que por ejemplo tomando un universo de 10 variables, estas 10 independientemente pueden funcionar a la perfección, pero en conjunto, en determinada situación pueden causar un error, que quizá no será un error de aplicación, sino un error de lógica y a su vez obtener valores erróneos,
      • Trabajar con demasiadas pruebas puede hacer que uno caiga en la desesperación como en este caso , que por cierto tiene gran  parte de razón, ya que las pruebas se pueden extender infinitamente, y un proyecto que pudo desarrollarse en 3 meses podría extenderse 2 años por el puro echo de ir programando pruebas, a la hora de hacer las pruebas, hay que saber en que punto detenerse.
      • Algunas personas llegan a creer que por el echo de que la aplicación haya pasado las pruebas unitarias significa que ya esta lista para irse a producción: Lamentablemente aun hay personas y empresas, que toman a menos a los encargados de pruebas, quizá  por que en muchos casos se contrata a  personas sin – o muy bajos – conocimientos técnicos y esto hace que los programadores y jefes de proyectos tomen a menos a los del área de pruebas. – aunque si hay casos en el que el razonamiento es justificado –; esto sumado al ego – si, ya se, estoy desvariando, los programadores no tenemos el ego grande, ni tenemos complejo de todopoderosos, son alucinaciones mías –, han llegado al punto de hacer que en ciertos casos los programadores minimicen o ignoren errores reportados – me consta- , los cuales luego tronaron – fallaron – en producción y trajeron muchos dolores de cabeza, este tipo de problema es algo complejo de resolver, por que escapa a lo “profesional” y se va a lo personal. algo que si es definitivo es que a pesar de todas las pruebas unitarias que le hagamos, aun la aplicación debe de pasar por un proceso de pruebas,  algo mas especializadas y quizá no automatizadas.
      • Las pruebas Automatizadas no aseguran que la aplicación este libre al 100% de errores :  ya que muchos de los causantes de sitios web hackeados, son por vulnerabilidades que las pruebas automatizadas no detectaron, sino miren el ejemplo de MS y que le paso por confiar en sus pruebas automatizadas , por eso es casi de ley hacer pruebas de esas que son basadas en el “ojímetro” – espero poder dar ejemplo prácticos sobre esto en un futuro no muy lejano – 
  3. Verificar que la prueba falla:
    • Aquí verificaremos que el error se presente… el problema es que pudimos habernos pasado unos 30 minutos o 1 hora escribiendo cierta prueba, que a las finales no falla, y no necesariamente por que la prueba este mal, lo que implicaría de nuevo una perdida de tiempo, aunque a su vez nos podría confirmar que X funcionalidad trabaja correctamente.
  4. Escribir la implementación:
    • aquí escribimos la funcionalidad de la aplicación, la cual deberá integrar  las validaciones necesarias  para poder superar la o las pruebas, en teoría – si estuviéramos en con Alicia en el país de las maravillas – la aplicación debería de funcionar sin problemas, la codificación de la aplicación debería de ser mínima, lamentablemente es algo que no pasa muy seguido a menos que el programador ya tenga una amplia experiencia,  lo cual nos saca del foco del “programador promedio”.
  5. Ejecutar las pruebas automatizadas:
    • Aquí la aplicación debería de pasar todas las pruebas, pueda darse que la aplicación pase las pruebas a la primera corrida, pero esto no implica que este libre de errores, solo indica que puntualmente la aplicación esta respondiendo  con determinados datos, pero no a todos
  6. Eliminación de duplicación:  aquí vamos refactorizando, algo útil, que a su vez es una inversión, este proceso no es malo, siempre y cuando se haga mesuradamente, ya que existen personas que se trauman demasiado con la optimización – si, ya se, estarán pensando “perro hablando de pulgas” – y hacen que se pierda demasiado tiempo en esto.
  7. Actualización de la lista de requerimientos: como el nombre lo dice, reordenamos los requerimientos y si es posible a repetir el proceso!.

 

Mi Experiencia Personal: no es exactamente TDD, pero usaron el modelo de pruebas.

Creo que ya lo conté en algún post…, no me canso de ponerlo, por el impacto del proyecto – de algunos millones de pesos – , erase un soft, al cual se le hizo un listado de requerimientos, y fue construido tal cual los requerimientos, el soft había pasado las pruebas planteadas en los requerimientos; si uno usaba el soft  tal cual indicaba el manual – las funciones puntuales trabajaban a la perfección – la aplicación funcionaba súper bien, el problema era cuando alguien daba un clic de mas, o presionaba en otro botón,  o hacia cualquier acción no contemplada en el proceso del manual de usuario; en ese momento la aplicación tronaba, fallaba,hacia BOOM…, no participe en la construcción de ese proyecto, aunque si en la destrucción – viendo como tronaba igual al pop corn-  cual fue su error? basarse “exclusivamente” en las pruebas echas en base a los requerimientos, y no ir “mas allá”  error en el cual algunos caen por que se confían demasiado en “las pruebas unitarias”, lógicamente esto también depende con que se cuente con un área de pruebas, ya que existen empresas en las cuales el programador tiene que hacerlas de tester, y eso puede volverse un gran problema.

 

Mi Opinión  y conclusiones :

El echo de que TDD exista, es por que hay personas a las cuales les funciono, pero antes que nada tenemos que tomar en cuenta el tipo de personas que lo usan, ya que de acuerdo al nivel de las personas, es que podemos hacer determinadas cosas, por ejemplo yo no podría hacer algo al mismo ritmo de alguno de los Scott – que salen por todos lados – , o un recién egresado a mi ritmo, por lo mismo no todas las metodologías funcionarían con todas las personas – por mas que la teoría diga que si se puede.

Escribir las pruebas antes que la aplicación, en la mayoría de casos – por no decir casi todos-, involucra que el programador realice funciones que no le corresponde, por eso mismo, personalmente prefiero las pruebas luego que el código de la aplicación y mas aun, prefiero que el que escriba las pruebas sea uno encargado de pruebas, así el programador se enfoca básicamente a programar la aplicación, aunque podría ir escribiéndose las pruebas y la aplicación en paralelo, esto depende de si se cuenta con personal capacitado para esto – si el de pruebas sabe programar pruebas, o solo es un pica botones –

Por que no estoy muy conforme con TDD? 

como ya lo puse, así como el modelo lo muestra, – y como es implementado normalmente- el programador tiene que hacer las pruebas y la aplicación, lo que implica  doble trabajo y hacer tareas que deberían tocarle a otras personas; estoy totalmente de acuerdo en que se deben de hacer pruebas, pero a mi parecer, lo debería de hacer alguien mas,  y mas aun que esta persona debe de estar integrada al equipo desde la etapa de diseño – esto es del siguiente post – . Lógicamente existen en nuestro medio personas excepcionales, que programan a una gran velocidad, y estas personas pueden programar pruebas y la funcionalidad  aun en menos tiempo, de lo que un programador promedio podría hacerlo, si esta fuera la situación,  que se da, en no todos los casos, pero se da,  allí no tendría ningún problema con que el programador haga las pruebas que quiera; pero lamentablemente esto no pasa en todos los casos.

Jorge Gamba me dijo vía twitter que BDD es mejor que TDD… ya habrá tiempo para opinar sobre eso.

Para terminar creo que TDD no es del todo malo, siempre y cuando se apliquen pruebas exhaustivas aun luego de que estas pasen las pruebas unitarias o pruebas automatizadas, confiar “solo” en estas pruebas unitarias, seria un grave error – se que Jersson dirá de que en TDD tbm se hacen pruebas – , el problema que hay es cuando personas con poca experiencia en el desarrollo de software usan esta metodología, es muy fácil que sientan que con las pruebas unitarias, ya tienen todo a la perfección y alli empiezan los problemas.

 

por si alguien quiere saber las mensadas que suelo poner – y que no llego a poner aquí por lo corto de las ideas, pueden encontrarme en  el twt http://twitter.com/ddaz – y lo de las mensadas es muy en serio eh xD –, se que dicen que el twt no es un chat, pero hay ideas que hay que  replicar en caliente, sino se va la inspiración.

espero sus opiniones y retroalimentación al respecto, no olviden que es mi apreciación personal :), quizá se me paso escribir algunas cosas que en este momento no se me vienen a la mente… pero de todas maneras este paso a ser otro “Testamento de Dacito”, veamos cuantos llegan a leer hasta este punto.

 y como lo prometi….  lo publique antes de irme a dormir… siendo las 3:36 am.. fugo para dormir…

Salu2

 

Ddaz – El Dacito –

28 comentarios en “Mi Opinión y Experiencia Personal sobre TDD – y de por que NO estoy MUY de acuerdo con el –”

  1. Uffff la que se va a liar …. jejeje pero es bueno que surjan este tipo de debates, voy a ver si, y espero que no te molestes, preparo una respuesta en mi blog para esto.

    Pero ya te digo que con esto correrán ríos de tinta, y vuelvo a repetir, me parece perfecto, cuanta más debate se genere, más se avanza 🙂

  2. Ponerte a hacer tests de unidades así por que sí normalmente lleva a perder mucho tiempo, hay muchas cosas que se pueden probar de un golpe cuando ya están acabadas con tests de funcionalidad. Si en los tests de funcionalidad funciona casi todo a la primera nos podemos ahorrar un montón de tiempo en tests de unidades.

    Si piensas que en un caso concreto escribir una prueba antes del código te puede venir bien pues lo haces, pero en la práctica no creo que haga falta muchas veces.

    Lo que hay que hacer siempre es usar el sentido común y no fiarse ciegamente de las recetas.

    Como dijo Knuth:

    As to your real question, the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

    http://www.informit.com/articles/article.aspx?p=1193856

    Según él los “unit tests” solo vienen bien cuando uno está muy perdido y no tiene ni idea de lo que va a funcionar y lo que no. En casos normales se pierde mucho tiempo.

  3. Como me citas al principio, no he podido resistirme a hacer unos pocos comentarios 🙂

    1, No todos los programadores tienen el mismo nivel, cierto Linus no necesita documentación 🙂 y el orgullo como dices es el orgullo. Hay que procurar trabajar siempre con gente que sabe más que uno. Solo por eso la programación por parejas merece la pena. Siempre se aprende.

    2 y 3 No todas las metodologías sirven a todos, cierto, de hecho además las metodologías se suelen adaptar en cada empresa; se siguen unos criterios básicos pero con variantes.

    4, Coincido, pero los programadores creo que deben tener más en cuenta las pruebas a la hora de codificar, por el hecho de que tengas alguien detrás haciendo las pruebas, el código cuanto más sencillo sea tiene más probabilidades de probarse de manera sencilla.

    5, Bueno, esto es muy discutible, existen multitud de tipos de pruebas, no solo debemos probar lo probable sino también lo improbable. Seguramente te estás refiriendo a pruebas con BBDD.

    6, No considero que las pruebas sean una manera de medir el software. Heisenberg, por supuesto tiene mucha razón y por eso la certeza en la sencillez de las soluciones es prácticamente imposible.

    Puntos acerca del TDD

    1, Tomar requerimientos nunca ha sido fácil (de hecho yo lo considero una de las partes más complejas del proceso de desarrollo)

    2, Lo bueno, en todo estoy de acuerdo.

    2, Lo malo, La división entre programador y programador encargado de pruebas nunca me ha gustado (ojo, en muchos sitios se hace así, y con buen resultado), mi visión es distinta, desde el punto de vista que el programador tiene que hacer código libre de errores, si hace él las pruebas mejor que mejor. A “mi gusto” mejor dos programadores haciendo sus pruebas que un programador y un programador para hacer pruebas.

    No entiendo muy bien lo de intentar cubrir todo, no sé si hablas de cobertura.

    Las pruebas, efectivamente en ocasiones pueden ser más difícil de plantear que el código en sí, es verdad, es una cosa que pasa, y requiere pericia y paciencia, y dividir muchas veces una prueba en varias, aquí puedes añadir el hecho de tener que refactorizar no solo el código si no también las pruebas, cosa que también es cierto. Hacer pruebas no es sencillo.

    También es cierto que hay gente que cree que es una pérdida de tiempo escribir pruebas antes que el código. Otras no, yo creo que escribir la prueba antes que el código ayuda y mucho.

    Solo como anécdota, hay bastantes empresas en Europa que subcontratan los desarrollos, la empresa escribe solo pruebas como especificaciones.

    También es cierto que el número de pruebas no garantiza el cien por cien del funcionamiento, y a veces también como dices puede ser engañoso, hay empresas que buscan una cobertura lo más alta posible en sus pruebas sin tener en cuenta como se están haciendo estas. Cuando algo falla, lo primero se escribe la prueba que falla y después se soluciona el problema.

    El caso que comentas de tener pruebas que en ocasiones fallan y a veces pasan, sin explicación aparente también es un hecho que ocurre, lo mismo que he comentado antes, las pruebas no son fáciles. Este comportamiento lo puedes ver en (http://xunitpatterns.com/Erratic%20Test.html) , que por si fuera poco uno además de los patrones de código tiene que aprender los patrones y olores de las pruebas.

    Trabajar con muchas pruebas, a mi me da seguridad; No sé cómo puede causar desesperación, es como tener una red cada vez que cambias el código.

    Lo de que se puede creer que al pasar las pruebas algo está listo para producción, es un error tan garrafal que no lo voy a discutir aquí. Si que diré que cuando alguien cambia alguna línea de código por el motivo que sea y sube las cosas al repositorio y se hace un build, y los tests pasan, hay cierta confianza en que puedes enviarle al cliente una nueva versión.

    Las pruebas automatizadas, las pruebas en general no garantizan al 100% de que todo este correcto, es cierto, pero con una confianza del supongamos 50% estas un 50% más tranquilo.

    3, Verificar que la prueba falla, si escribes antes la prueba, siempre escribes algo que falla. No creo que una prueba que escribas a posteriori para producir un fallo, te lleve tanto tiempo, pero como hemos comentado antes, es cuestión de pericia.

    4, Cierto, puede que el TDD no sea para todo el mundo.

    5, Esto ya lo has dicho antes con otras palabras.

    6, Eliminación de duplicaciones y optimización son dos cosas distintas, en cualquier caso el TDD, precisamente evita el sobre diseño.

    7, Los requerimientos siempre, siempre cambian y hay que tenerlo en mente.

    Bueno, en cuanto a tus opiniones personales, tan buenas como las mías, cada uno tiene su punto de vista, y se ha de respetar. En cualquier caso me encanta poder leer las experiencias que cada uno tiene, son puntos de vista diferentes y siempre enriquecen.
    Un Saludo,
    Carlos.

  4. @David, me parece muy interesante abrir discusiones sobre este tema que tanta controversia crea.

    En mi opinión creo que las ventajas de las pruebas unitarias no son comparablaes a sus desventajas, sobre todo en sistemas de cierto tamaño, la detección precoz de errores y el testeo continuo hacen que pronto se recupere la inversión, estoy de acuerdo en que escribir la prueba simultáneamente con el código es algo para lo que no todos estamos preparados, después de intentarlo varias veces, no acabo de ver muy bien la diferencia aunque pienso que lo verdaderamente importante es tener pruebas unitarias y consecuentemente cobertura de código.

    La realización de ciertas pruebas las deberían realizar Tester especialidos integrados en el equipo de desarrollo ya que estos tienen una visión diferente del desarrollador que sabe perfectamente cómo funciona el programa y en ciertos casos puede condicionar la prueba a su conveniencia.

    Las pruebas no establecen que la aplicación funcione al 100 %, pero si garantizan que la mayor parte de las funciones independientes con suficiente cobertura realicen aquello para lo que ha sido diseñadas, esto ya es una aportación que por sí sola hace que merezca la pena utilizarlas, cuantas veces cambiamos una función y nos damos cuando la ponemos en producción que esta no funciona como debería, las pruebas permiten detectar estos errores con rapidez, antes de su puesta en producción, en ciertos entornos es muy importante, imaginate alterar una función en un cálculo financiero de un banco… aunque estoy de acuerdo con lo que dices, creo que también se deberían realizar pruebas de funciones en conjunto tal y como hacen las aplicaciones. Pero esto es algo que tambien se puede hacer.

    Creo que los entornos de pruebas unitarias deben evolucionar mucho. En la nueva versión de visual studio podremos crear pruebas sobre los interfaces en WinForms, esto ya una gran ventaja, en mi equipo hay una persona que se pasa casi todo el tiempo realizando pruebas sobre formularios y controles, si pudiese automatizarlo sería de gran ayuda y ahorraría mucho trabajo.

    Uno de los problemas actuales es el rendimiento en Visual Studio, sobre todo en proyectos donde existe un gran número de ellas, espero que mejore en las siguientes versiones pero hay veces que ejecutar las pruebas se convierte en un ejercicio de paciencia demasiado pesado.

    Aún así, con todos sus problemas e inconvenientes sigo pensando que las aportaciones de las utilización de TDD es infinitamente superior a sus desventajas.

    Saludos.

  5. TDD y Unit Testing son muy útiles, pero no son los únicos tipos de pruebas que deben hacerse a un producto de software. Para una explicación exhaustiva de esto recomiendo el libro “Agile Testing: A Practical Guide for Testers and Agile Teams”.

    No estoy de acuerdo cuando dices que “escribir pruebas para la aplicación es algo que no le corresponde al programador”. Algo más adecuado sería decir “escribir pruebas para la aplicación es algo que NO SOLO le corresponde al programador”. Si el programador no escribe pruebas, con que confianza va a refactorizar el código? con que confianza va a agregar nuevas funcionalidades? con que confianzar va a poder decir “terminé con esta funcionalidad”? con que confianza va a poder integrar su código con el de otros desarroladores? con que confianza va a modificar el código meses depués de haberlo escrito?

  6. David,
    creo que no hemos hablado de TDD asi que considero no deberias mencionar mi opinión al respecto,
    Solo para cerrar este comentario puesto tengo muchas ideas pero si poco tiempo:
    – TDD es una buena alternatvia para el desarrollador, como tecnica de desarrollo, no pruebas.
    – Esta dicho, que TDD no te asegura el 100% de la caldiad de tu entregable, pero si es bien aplicado disminuyen los bugs tontos y muchas veces gran mayoria de consideraciones funcionales.
    – Desde mi punto de vista TDD permite que la gente de pruebas, prueba de verdad, orientandose en el producto, no en cosas que se podian haber escapado al desarrollador, y todo esto gracias a tener bien definido un criterio de aceptación.

    En fin, seamos francos, TDD no tiene uno o dos meses, no es falto de seriedad, y mas aun, tienes que aceptar que por algo ASP.net MVC lo saca a relucir por todos lados o por ejemplo que VS2010 tendra soporte nativo.

    Te recomiendo le des una oportunidad y posterior revisada, pero no tanto que te metas al código, sino veas sus fundamentos de trabajo, como técnica de desarrollo.

    Bueno,un abrazo.

  7. mi opinion es sobre tus razones de porque no estas conforme con TDD:
    “el programador tiene que hacer las pruebas y la aplicación, lo que implica doble trabajo y hacer tareas que deberían tocarle a otras personas; estoy totalmente de acuerdo en que se deben de hacer pruebas, pero a mi parecer, lo debería de hacer alguien mas”

    Esta razon me parece muy bastante desafortunada, las pruebas unitarias no son doble trabajo, son una forma de asegurarte que tu codigo hace lo que tu quieres que haga, sin tener que esperar a que alguien mas descubra tus errores, ademas de que en el futuro cuando tengas que hacer cambios a ese codigo automaticamente sabras si introduciste algun error.

    Cuantas veces no se introducen errores nuevos al hacer cambios al sistema?
    cuantas veces se entrega un sistema para que a los pocos minutos te dicen que no funciono?

    El problema en todo caso, es caer en excesos, pero eso no tiene nada que ver con la metodologia.

    Por ultimo quisiera aclarar que TDD no se centra en testing, TDD se centra codigo bien diseñado, y precisamente por eso es que han salido BDD, DDD, etc, porque los que crearon TDD la cagaron con el nombre

  8. Estas cometiendo un craso error al enfocar TDD hacia aseguramiento de calidad.
    No leí tu post completo, es demasiado largo y opinativo, pero siento el espíritu en general.

    TDD es sobre el diseño de la aplicación, sobre aplicar los patrones correctos, escribir la menor cantidad de código funcional necesario y sobre pensar acerca de la API.

    Los efectos colaterales son los que mucha gente confunde con los objetivos:
    – malla de seguridad contra regresiones
    – ejemplificación y documentación funcional del código
    – etc.

    Los test unitarios NO reemplazan las pruebas funcionales.
    No hay reemplazo para un buen Tester. No hacer testing funcional y de interfaz de usuario es un error que pagas muy caro. TDD o no TDD.
    Si alguien hace TDD para evitar hacer Testing, no entiende la realidad del desarrollo de software.

    Además, TDD es una técnica de desarrollo, no te dicta el exito/fracaso ni te otorga métricas de estado de proyecto por si solo. Para eso necesitas una metodología de seguimiento de proyecto, independiente de la técnica de desarrollo.

    Ese es el problema, no hay que mezclar los conceptos ni creer en las panaceas. no existen.
    Dicho eso, TDD es una excelente metodología de desarrollo que te asegura estar en linea con los requerimientos, minimizar el código y complejidad además de ayudarte a hacerlo aplicando patrones.
    El resto, sigue tal como siempre.

  9. No es mi post, pero …

    @juan – Vamos acercando puntos de vista 🙂

    @gustavo – Totalmente de acuerdo

    @jersson – Totalmente de acuerdo

    @eber – Totalmente de acuerdo, tal vez si la cagaron con el nombre.

    @delmo – No cuesta tanto leerlo :-), si no has leído el post supongo que menos los comentarios.

    Sigo insistiendo en que TDD no es fácil, que estoy seguro que la mayoría coincidís con esto, cuesta, al igual que hacer tests después de escribir el código, hay que acostumbrarse pero una vez que se hacen, no puedes vivir sin ellos.

  10. Ummm varias cosas…

    Llevo 15 años desarrollando software, he conocido muchas técnicas y herramientas, si tengo que elegir la técnica que más a impactado en mi forma de desarrollar (logicamente para bien) es el uso de un gestor de fuentes, la segunda, a muy corta distancia es el uso de testeo unitario.

    Los motivos suyacentes de por que el testeo unitario funciona los ha expuesto de sobra Carlos Segura. Recomiendo también la lectura de la serie de post que ha escrito Ibon Landa.

    Por último, creo que todos los comentarios que están en contra de TDD o del testeo unitario en general, incluido el post principal, denotan un profundo desconocimiento de en que cosiste TDD y las pruebas unitarias y por supuesto de sus ventajas cuando se aplican a proyectos no trivales.

    Como pasa con Scrum, RUP y demás, por seguir con el simil, hay mucha gente que piensa que hace TDD o pruebas unitarias, y en realidad esta haciendo el indio.

    ¡Saludos!

  11. Estoy totalmente de acuerdo con lo que menciona Eber Irigoyen, Esa ‘T’ de Test en TDD, ha permitido muchos malosentendidos como que se use TDD como simplemente ‘Testing’, entonces se pierde el valor como técnica de desarrollo.

    Por eso comentaba a David por twitter que BDD es mejor, porque usa las ventajas y métodos de TDD pero involucra más al cliente, usando un lenguaje común incluso en el código, en el diseño de requerimientos y pruebas de aceptación, lo cual es perfecto porque es muy compatible con metodologías Agile, además, permite tener una visión más amplia que simplemente una Fixture.

  12. Dudo bastante que el ganador del Premio Turing, la Medalla John von Neumann y el Premio Kyoto (el equivalente japonés del Premio Nobel), el profesor emérito de la Universidad de Stanford Donald Knuth tenga un profundo desconocimiento de lo que son las pruebas unitarias cuando habla sobre ellas.

  13. Hola:

    luego de una ciesta -sakura me dejo dormir recien a las 5 am – ahora ya me puse a checar, y veo varios comentarios, casi casi para poder responderles, tendria que escribir otro post, veamos si puedo resumirlo bien.

    Antes que nada, quiero aclarar que “No estoy Afirmando que TDD este mal”, ni “Tampoco que TDD sea puramente testing”, simplemente me enfoque en las partes a las partes que explicarian mi punto.

    No estoy en Contra de las Pruebas Unitarias, ya que pienso que mientras mas pruebas se les haga a la aplicacion es mejor.

    @Rafael personalmente uso las pruebas unitarias, no me parecen malas, logicamente no como algo “unico”, creo que mientras mas pruebas realicemos la aplicacion podria salir con menor cantidad de errores.

    @Luis Estare esperando el post respuesta.

    @Carlos : sin querer queriendo le diste en el punto que queria dar, ya que No tengo nada en contra de las pruebas unitarias, aunque a su vez creo que no aplica en todos los casos o con todos los equipos; pero en el ejemplo que das, afirmas que subcontratan a una empresa para que genere las pruebas… y es justo lo que estaba diciendo, que el desarrollador  no tiene necesariamente por que hacerlas, tarea que se puede dar a otra persona y asi el programador se dedica a programar. ya sera en paralelo o despues.

    Los errores y las fallas son cosas casi inevitables, ya que en la escuacion esta el factor humano.

    en Resumen : TDD no me parece malo, pero no me parece aplicable en todos los casos o  con todos los equipos – depenede del equipo con el que se trabaja y que cualidades tenga –

    continua …..

  14. continuando

    @Juan Acepto que unas pruebas  bien diseñadas, y bien escritas son de muchisima ayuda para la aplicacion, son pruebas y las pruebas ayuda, el problema va cuando se hacen pruebas redundantes, o innecesarias por que estas ya fueron tocadas por otras, esto normalmente pasa con personas con poca experiencia, o con con muy poco tino en cuestiones de pruebas…, ya que no todos tienen el “don”, asi como no todos pueden entender a generics, o a una simple recursividad… hay quienes de plano no pueden con las pruebas unitarias, pero mientras se pueda, adelante.

    @Gustavo  tienes razon en el “no solo”, aunque si habia puesto, que hay quienes si tienen la capacidad y quienes no, de todas maneras prefiero que no sea el programador  el que este escribiendo las pruebas, para que asi tenga tiempo de dedicarse a programar, logicamente cuando hay alguien que tenga la capacidad de escribirlas – y no sea otro programador-, para ahorrar recursos.  sobre las cuestiones de confianda… que sepa o no sepa hacerlo, no implica que necesariamente tenga que hacerlo, ya que yo puedo saber de servers, pero en un proy en el cual soy solo desarrollador, no puedo “por mis ganas” ponerme a moverle al server, y eso no implica que deje de conocer un server, o que si se requiere pueda modificarlo.

    @Jersson  Todas las tecnicas / metodologias afirman disminuir la cantidad de errores, cada una con sus procesos diferentes, como ya puse antes, no estoy en contra de TDD, lo que si es que  ciertas circunstancias pueden ocacionar  que esto se vuelva en contra de uno, asi como en las pruebas, son buenas, pero si son bien utilizadas,  como ya dijiste, no asegura – aunque intenta – anular los errores,  no digo que TDD tenga falta de seriedad, puse ciertos factores que pueden volverlo perjudicial, ya que tu bien sabes no todas las tecnicas / metodologias  aplican para todas las personas .  y sobre MS, creo que en este momento no es buen punto de medida, ya viste como se apresuraron y sacaron Linq2SQL  y lo promocionaban contra viento y marea – y lo integraron al IDE –  y a las finales los resultados demostraron que se equivoco y tuvieron que ponerlo a un lado .. asi que en este momento MS a mi parecer no es un buen referente, ya que quedo muy en deuda. Ademas de que afirme alli mismo de que si TDD existe es por que hay personas a las que  les a funcionado, es algo innegable, aunque no a todos, asi como no todos estan a favor de RUP y se van a scrum.

    Eber : No estoy diciendo que NO se hagan las pruebas unitarias, pienso que pueden hacerse tales pruebas, pero no necesariamente el programador, el cual puede seguir programando como se lo dicta TDD,  haciendo que su codigo responda a la prueba, pero esta no la codifico el, asi cada uno se dedica a los suyo, y se ahorran tiempos.

    @Delmo : Aunque no leiste todo el post, le atinaste tambien a lo que queria decir, ya que alli puse  que estas pruebas NO son absolutas, deben de hacerse las pruebas normales luego, lamentablemente hay quienes toman estas como absolutas y  es cuando falla todo el proceso, ya que este tipo de pruebas no comprueba todo. tecnicas hay muchas, y todas ofrecen ayudar.. en diferente forma, el detalle es que no todas tienen el mismo resultado  en todos los equipos de trabajo, depende del tipo de personas con el que cuentas, para saber que metrica o forma de trabajo utilizar, por cierto , gracias por leer, aunque sea una parte; si alguna vez te das tiempo, leelo completo.

    @Carlos  de nuevo, tu lo has dicho, no es facil  y por lo mismo no a todos les va a funcionar, si a ti te funciona es excelente, pero no todos tendrian el mismo resultado.

    @Rodrigo  si te fijaste en el texto – hasta te mencione –  no estoy en contra de las pruebas unitarias, ni tampoco al 100% en contra de TDD, lo que plante fueron ciertas situaciones que pueden hacer que el proceso fracase, y ademas  que a mi parecer estas pruebas las puede hacer otro, y no necesariamente antes del codigo – algo que tu tbm has puesto en otro post -, como ya repeti muchas veces, TDD no te asegura el exito, ya que por mas bueno que sea, no todas las personas pueden responder igual a todas las situaciones, por lo mismo no todas las tecnicas aplican para todas las personas, hay quienes si no tienen 100000 hojas de documentacion no pueden compilar sus pensamientos, asi como hay personas que solo ocupan unas 4 hojas y ya entendieron todo, del mismo modo  hay programadores que ponerlos a hacer pruebas unitarias es como a un literario ponerlo a debatir de la teoria de la relatividadl logicamente si tienes un crack en el equipo, le puedes poner la tarea que quieras y  te lo podra hacer, lamentablemente no es en todos los casos  y no siempre esta al alcance $ del presupuesto.

    @Jorge No solo le cambiaron la letra… tbm cambiaron enfoque… xD, y claro que entiendo que TDD no implica solamente pruebas… eso lo tengo muy claro desde antes de escribir el post…. solamente hice enfasis en ciertos puntos, no soy un especialista entrevistando clientes, asi que no me siento seguro opinando de un tema asi, en cambio  aunque no sea un Guru en pruebas y seguridad – pero algun dia lo sere!!-  siento que tengo algo de experiencia y practica y por eso me enfoque a ese tema en espeficico.

    @Alfredo :  no pude haberlo dicho mejor que tu 🙂

     

    Salu2

    Ddaz

     

     

  15. @Alfredo Con todo el respeto y admiración que puede despertar Knuth, él es un científico computacional, no un desarrollador o “software craftsman”. Esto quiere decir que el grueso de su experiencia profesional va por el lado académico. Hasta dondé se, no tiene mucha experiencia trabajando en equipos de desarrollo para clientes reales resolviendo problemas de otras personas bajo restricciones complicadas de tiempo y presupuesto.

    Por lo tanto, opino que su conocimiento del tema va mucho más por el tema teórico, pues obviamente no ha tenido la necesidad de emplearlas exhaustivamente.

  16. Gustavo, parece que no estás muy bien informado. Knuth tiene más de 50 años de experiencia como desarrollador y ha creado más de 1000 programas bastantes de ellos grandes y complejos como TeX y METAFONT, usados por millones de personas. Y además es uno de los teóricos más importantes de la historia de la informática. Así que decir alegremente que no tiene ni idea de lo que habla es como poco bastante imprudente.

  17. @DDaz, no me has entendido lo de la subcontratación, creo. Primero la empresa Europea que subcontrata escribe los tests (como de requerimientos se tratará) y encarga el código que debe pasar esos tests.
    TDD,BDD, o ATDD todas me parecen buenas prácticas.

    Y también coincido en que se llega a soluciones distintas, porque en un experimento que estamos realizando, con tres programadores, todos con los mismos requisitos haciendo el mismo programa y dos usando TDD, y el último no. Llegan a tres implementaciones distintas. Pero lo que hemos observado es que las implementaciones basadas en TDD a son más sencillas, fáciles de ver por un cuarto programador que se ha mantenido al margen y por supuesto más testables.

    (ya comentaré sobre el CodeDojo que estamos preparando en NavarraDotNet sobre TDD)

    Como dije en un principio, no existe la certeza de que estamos ante una implementación y un diseño lo más simple posible, pero debe ser la meta a alcanzar.

  18. Carlos, me imagino que esos tests que escriben las empresas Europeas muchas veces no son tests unitarios sino tests de funcionalidad.

    Los tests unitarios tendrían sentido si se subcontratasen algunos módulos, pero si se subcontrata todo el desarrollo quienes tendrían que hacer los tests unitarios en caso de que los hubiese serían los de la subcontrata, y los test de funcionalidad que son los que de verdad valen los haría la empresa europea.

    Los experimentos con 3 programadores no son muy fiables que digamos. Puede ser que coincida que los programadores que usan TDD sean mejores o estén más inspirados o motivados o pura casualidad. Haría falta una muestra mucho más grande. Así no es más que evidencia anecdótica.

    Según la Wikipedia los estudios no han encontrado correlación entre el uso de TDD y la calidad del código ni entre TDD y productividad.

    Lo que no veo por ninguna parte es la posible relación entre TDD y simplicidad de diseño. No le veo sentido.

  19. Además ahora con sistemas de pruebas automáticas como Pex, escribir las pruebas antes que el código va a tener mucho menos sentido por que estas herramientas te generan automáticamente las pruebas a partir del código.

  20. @Alfredo

    Con este comentario:

    “Además ahora con sistemas de pruebas automáticas como Pex, escribir las pruebas antes que el código va a tener mucho menos sentido por que estas herramientas te generan automáticamente las pruebas a partir del código.”

    has demostrado que no sabes en que consiste TDD, con lo cual.

    Y no me entra en la cabeza que nadie haya dicho algo sobre el hecho de escribir HECHO sin H en TODAS las ocasiones.

  21. No Alfredo, lo que no entiendes que TDD no se trata de escribir las pruebas antes, y por tanto tu comentario sobre PEX es irrelevante porque aunque escribas pruebas, eso no es el objetivo. Por tanto, no, no creo que hayas entendido el objetivo de TDD

  22. Yo nunca he dicho que el objetivo de TDD sea escribir las pruebas antes.

    El objetivo siempre es ganar dinero, y si aparecen herramientas nuevas que nos hacen los tests después gratis entonces es más difícil de justificar el hacerlos antes a mano.

    Eso de que el código queda mejor si haces las pruebas antes no está demostrado ni muchísimo menos, en cambio el que escribir pruebas a mano cuesta dinero es algo evidente.

  23. Pero lee tu último comentario, si es que un párrafo te contradices.

    1. TDD no es pruebas antes.

    2. Este post va de TDD.

    3. Dices “yo nunca he dicho que el objetivo de TDD sea pruebas antes” sin embargo más arriba dices:

    “Ahora va a resultar que lo del TDD no dice que se escriben las pruebas antes que el código y que me lo he inventado yo.”

    Eso implica que para ti se trata de escribir pruebas.

    4. Dices “tests después gratis entonces es más difícil de justificar el hacerlos antes a mano.”

    De nuevo, es que no se trata de pruebas. Nadie discute esto, pero este post habla de TDD

    Y no, nadie salvo la experiencia de cada uno puede decir si TDD le ayuda a simplificar y mejorar su código. Evidentemente si no has hecho TDD no puedes hacer esa afirmación ni negación. Yo si lo puedo hacer si llevo con TDD más de 2 años y he estado sin TDD también.

  24. Se ve que tienes problemas con la lógica y con la comprensión del español escrito. Así que mejor dejarlo.

    Con respecto al último párrafo, las personas y algunos animales tienen la capacidad de prever las consecuencias de acciones antes de efectuarlas. Algunos más que otros, claro.

  25. Como dijo Luis Fraile al principio:

    “Y corrieron ríos de Tinta!”

    Para mí, TDD rompe el mito de que las pruebas (más allá de cuándo se hagan) están aisladas del proceso de construcción.

    Comparto también lo dicho por Jersson, TDD permite que el tester pruebe lo que debe probar, LA FUNCIONALIDAD…pruebas reales de negocio y no un …”a ver si le meto 2 y 3 me debería dar 5″.

    La verdad, no tengo claro cuales fueron los orígenes exactos de TDD pero veo una conexión conceptual con un principio de Lean Software Development que dice algo como “Probar desde el principio” para “Construir con calidad desde el principio”.

    Slds,

    Raúl

  26. @Alfredo,

    Para mi un debate termina si empiezan los insultos. No te conozco de nada pero he estado mirando en otros blogs y foros donde dejas comentarios y veo que en casi todas las conversaciones al final recurres a los insultos. Yo no jugaré ese juego contigo. Lo siento.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *