lupaSiendo alguien que vive los beneficios de hacer TDD, creo profundamente en el desarrollo guiado por pruebas. Esta práctica agrega un nuevo nivel de calidad y madurez al desarrollo de software, y sin embargo todavía no es la técnica más usada en los proyectos de software. Cuando hay que elegir entre características, tiempo y calidad, siempre sufre la calidad. No queremos agregar tiempo extra para hacer pruebas, y tampoco queremos comprometer las características que vamos a entregar. Si no se pusieron como objetivo hacer TDD al iniciar el proeycto, es dificil hacerlo después.

Todos escuchamos excusas para no hacer TDD, pero nadie las juntó mejor que "Pragmatic Unit Testing in Java With JUnit", de la serie Pragmatic Bookshelf. Hace un par de años que leí ese libro, y desde entonces creo que no hay forma que un desarrollador responsable pueda leer este libro sin entender que las pruebas unitarias son uno de los aspectos más importantes del desarrollo de software.

La excusa más preocupante que escucho es que es demasiado dificil probar mi código. Esto puede ser por dos motivos. Uno es que el código sea principalmente de interfaces de usuario (UI), y automatizar las pruebas de UI es muy dificil. Entiendo que la automatización de UI son bastantes complejas (¡y no imposibles!), pero se debería dedicar todo el esfuerzo en automatizar lo más posible: piensen en las pruebas de regresión. Si tienen una suite de pruebas completamente automatizada, incluyendo el comportamiento del UI, podrán hacer cambios al código con total confianza de no romper nada.

El segundo motivo de que el código es demasiado dificil de probar es que hicieron desastre con el diseño. Quizás la lógica y el código de UI están muy acoplados. Es por esto que TDD ayuda a mantener un diseño limpio, siguiendo las mejores prácticas. Usar JUnit es simple, y si puedo ejecutar toda la capa lógica por tener un diseño limpio, entonces podré probar toda la lógica que el UI va a usar. ¿Qué les falta el modelo de datos? Entonces pueden usar objetos mocks - ¡hay muchos frameworks para esto!

Para quienes todavía no leyeron el libro, les dejo un breve resumen de las excusas para no hacer TDD:

Escribir pruebas lleva mucho tiempo

Este es el principal motivo que dan los desarrolladores, y creo que se debe a cómo nos enseñan a desarrollar software. En general, nos hacen creer que la estapa de pruebas ocurre al final del proceso, y no durante todo el desarrollo.

TDD fomenta el modelo "pagar a medida que se avanza", en donde escribimos las pruebas mientras desarrollamos, por lo que no tenemos que meter tiempo al final del proceso para escribir todas las pruebas que podamos.

Y de todas formas, si no estás escribiendo pruebas a medida que avanzás, ¿cómo comprobás que el código se comporte como esperás? ¿Lo ejecutás manualmente? ¿No tiene más sentido invertir algo de este tiempo de pruebas manuales en escribir una prueba JUnit para esto? Quiero decir, en algún momento vas a tener que ejecutar esa porción de código - no va a quedar sin tocar el resto de la vida del producto.

De hecho, ocurren muchas más penalizaciones de tiempo si no se escriben pruebas unitarias. Vas a tener que gastar tiempo haciendo debug del código intentando averiguar porque algo no funciona. O vas a hacer un refactor, y luego darte cuenta que nada funciona como antes del refactor. Si tuvieras las pruebas unitarias, tendrías una base segura.

Lleva mucho tiempo ejecutar las pruebas

Si, puede llevarse bastante tiempo ejecutar pruebas que involucran a entidades externas, o pruebas de la interfaz de usuario. Pero se supone que hay más de un nivel de pruebas. Las pruebas unitarias deberían ejecutarse rápido, y podría haber un nivel de integración que también corra sin mucho impacto de tiempo. Si hay pruebas de integración que toman mucho tiempo, será cuestión de correrlas con menos frecuencia - quizás de manera nocturna. Esto no quiere decir que debemos ignorar las pruebas unitarias. Estas siempre deberían correr lo suficientemente ráipdo como para ser parte natural del proceso de software.

Mi trabajo no es probar el código

Todavía no sé en qué momento un desarrollador de software decide que puede tirar código contra la pared así nomás. Si nuestro trabajo fuera de "Codificador" quizás ahí tendríamos una mejor excusa. Pero nuestro trabajo consiste en desarrollar código que funcione, y por lo tanto necesitamos alguna forma de mostrar que nuestro código es funcional. Si a la gente de QA les cuesta encontrar bugs en nuestro código, va a ser maravilloso para nuestra reputación.

En realidad no sé cómo funciona el código, por lo que no puedo probarlo

Esta es dificil de tomar sin ser incrédulos. Si no entendemos cómo debería funcionar el código, no deberíamos empezar a programar. Primero debemos entender el requerimiento.

El libro tiene un par de excusas más, pero estos son las principales. ¿Qué excusas escucharon ustedes para no escribir pruebas?

Traducido de I don't write unit tests because... the excuses, por James Sugrue.
    • Invitado

      Una típica: Después hago el test

    • Hola: Yo estoy totalmente de acuerdo en que hay que hacer las pruebas unitarias antes y seguir TDD, las veces que lo he usado me han gustado muchas cosas. Sin embargo mi excusa para no usarlo siempre es simple: me aburro. A mi me encanta programar rápidamente cuatro líneas de código y verlas funcionar y luego ir incrementando funcionalidad y viéndolo sobre la marcha. Haciendo TDD (test-código-test-código...) de alguna forma se pierde ese encanto y programar se convierte más en un trabajo de rutina que en algo divertido. Para mi no tiene la misma diversión ver el programa funcionando desde ya e ir añadiéndole cosas, que ver una barrita roja-verde-roja-verde-... Se bueno.

    • Invitado

      test

    • Invitado

      ....tuviera tiempo de escribir un test. no hay tiempo, si vos decis que te va a llevar mas tiempo hacer un desarrollo no te lo dan para hacer, se lo dan al que lo hace mas rapido. aunque despues mantenerlo sea un infierno, pero para ese tiempo el proyecto ya está pagado. ademas podes cobrar por el mantenimiento. (pensamiento de consultoras)

    • Invitado

      Pasaselo a test para que les pagan???

    • Jose Martin Rangel

      Que tal mis estimados: Si les comento que una de las fuertes razones que no se hacen pruebas unitarias es porque quita un poco de tiempo al proyecto que de por si esta muy acotado en tiempos de entregas. He de confesar que hay bugs que no son mios y que me han costado dolores de cabeza para encontrarlos cuando modifico codigos de componentes que ya han sido creados y modificados por personas distintas. Pienso que si se hiciera pruebas de este modo se ahorraria uno estos problemas para si mismo y los demas. Como programador le tengo amor al arte pero el negocio indica que el tiempo es dinero y mientras mas rapido salga el desarrollo mejor para ellos.

    • Hector

      Ojala puedan agregar Un articulo orientado a mvc, o algun ejemplo real, Un problema que tenemos al querer comenzar es que solo existe el ejemplo de la clase que suma y resta, de cualquier forma gracias por compartir esto

    • Quizás te pueda servir, te dejo un proyecto que estoy desarrollando (de código libre), que tiene una muy buena cobertura de código usando JUnit. El proyecto está productivo en [url="https://www.mucontacts.com"]www.mucontacts.com y en uso actualmente, y el código junto con todas las pruebas lo podés descargar en [url="http://code.ideasagiles.com/mucontacts"]http://code.ideasagiles.com/mucontacts .
      No es una guía, pero te puede servir para ver un ejemplo real de TDD sobre un proyecto. Te recomiendo que empieces a mirar las clases de prueba, en particular las de los DAO que son los más simples (por ejemplo, PlanDaoTest o TagDaoTest), y veas los distintos escenarios que planteamos, y como se van desarrollando las pruebas.

    • dario

      El tiempo de desarrollo de los tests no está incluido en la propuesta. No hay tiempo para tests, se entrega con los errores corregidos por la gente de qa o los testers. esa es la realidad. Siempre gana el tipo que ofrece hacer por menos plata y en menos tiempo y eso excluye el tiempo de desarrollo de test.

    • Tihuilo

      Soy nuevo en el desarrollo de software y he escuchado sobre el tema paro no se por donde iniciar, como se implementa TDD, alguna sugerencia por donde comensar?

    • dario

      En donde trabajo se hacen 3 tipos de trabajo:

      RÁPIDOS - BARATOS y BUENOS

      PERO SOLO SE PUEDEN ELEGIR DOS OPCIONES

      Un BUEN trabajo RÁPIDO (no saldrá BARATO).
      Un trabajo BARATO y BUENO (no saldrá RÁPIDO).
      un trabajo BARATO y RÁPIDO (no saldrá BUENO).
      (ninguno incluye testing)

    Deja tus comentarios

    Post comment as a guest

    0

    Seguinos en Facebook.

    Publicá tus artículos.

    Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
    Quiero publicar

    Los Comentarios.

    invitado
    hasta ahora no sabia que era el cinismo pero ahora que lo se me he dado cuenta porque he tenido tant...
    Dai
    Es broma?
    busquen el significado de cinismo.
    esta el antiguo significado y el moderno,
    el moderno...
    Yan
    Hola:
    Unas duda, Drools ¿tiene una interfaz gráfica para poder generar y editar reglas? o todo se t...
    Maxi
    Gracias por la info, esta bien explicado y funciono como solución a mi problema que tenia con el mét...
    jonybuzz
    Cierto. Y más desafiante: Qué pasa si dejamos ir algo que sí funciona? Algo que sentimos que puede m...

    Inspiración.

    "Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

    Bernard Shaw