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 –


:) Publicacion cruzada desde Geeks.ms :) http://geeks.ms/blogs/ddaz

2 thoughts on “Mi Opinión y Experiencia Personal sobre TDD – y de por que NO estoy MUY de acuerdo con el -”

  1. Hola David, me ha parecido un artículo realmente interesante y me ha ayudado mucho para empezar a entender y ver los pros y contras de este método.

    En mi empresa, una cadena de supermercados internacional, estamos tratando de implantar el TDD (Test Drive Development) como metodología de pruebas, ya que todos los desarrollos son para departamentos internos de la propia empresa.

    Yo soy el responsable del diseño de dicha metodología, pero no se muy bien por donde empezar ya que nunca había oido hablar de ella y lo único que sé es a través de artículos de internet que he podido leer, tan buenos como el tuyo.
    Yo soy solo el becario de la empresa y no soy programador así que he tenido que estudiar bastante todo este mundo de las pruebas para ponerme al día, pero de programar no se nada. Después de leer artículos como el tuyo ya no se si merece la pena o no implantarlo. A mi me han dicho que hay que introducir una metodología ya que cada uno hace las pruebas como quiere sin ningún rigor ni control, yo había pensado en esta metodología del TDD, pero ya no estoy seguro de nada.

    He podido ver que eres un experto en el tema, por lo que te estaría enormemente agradecido si me pudierais ayudar con algún tipo de información o consejo que me permitiera empezar a diseñar dicha metodología en mi empresa de forma adecuada, ya que actualmente me encuentro algo desorientado al respecto. Tanto si es el TDD o en caso contrario cuál y cómo implantarías tu en un supermercado con desarrollos propios.

    Muchas gracias por todo. Espero que puedas ayudarme.

    Recibe un cordial saludo y mi más sincera enhorabuena por el artículo.

    Un abrazooo

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>