Le llamaban TDD…

En el blog de Luis Fraile, se ha planteado una interesante reflexión a raíz de unas palabra mías en el TTT. Vaya por delante el decir que creo no fueron del todo correctas desde un punto de vista purista. Yo afirmé algo como «en TDD da igual escribir las pruebas antes que después», cuando lo que debería haber dicho es: «En mi opinión, lo importante es escribir pruebas, da igual antes que después». Cuando una sala esta llena de gente de gran nivel, cualquier error es sacado rápidamente a la luz, algo que siempre ayuda: «Cuanto antes se descubre un error menos cuesta», dice una máxima de calidad del software. La corrección está hecha (no lo he visto pero seguro que Luis ya lo ha cambiado). En la ppt ahora hablará genéricamente de pruebas unitarias en lugar de TDD.


En TDD, sin duda, las pruebas se deben escribir antes. No es opcional si queremos decir que realmente seguimos las reglas de TDD. No hay discusión en esto si nos ponemos estrictos. Y los defensores a ultranza de está técnica esgrimen una serie de ventajas, que sin duda son ciertas, pero que en gran medida se obtienen también escribiendo las pruebas a posteriori.


En cualquier caso, desde mi experiencia, escribir las pruebas antes o después es un matiz que yo creo que se debe dejar en manos de cada desarrollador. Cada uno que haga lo que mejor le parezca y más cómodo le resulte. Quiero que los desarrolladores se sientan cómodos a la hora de escribir pruebas ante todo.


Yo, personalmente, uso un enfoque más bien mixto, eso sí cada vez más sesgado hacia escribir antes las pruebas. Hay veces que veo claro que test debo escribir y me lanzo ha escribirlos antes que la clase, hay veces que escribo primero la clase. Casi siempre que escribo los test antes, luego suelo tener que escribir alguna prueba más después para alcanzar cobertura suficiente. Tal y como yo lo veo, creo que escribir las pruebas antes, tiene una curva de aprendizaje mayor que escribirlas depués.


De todos modos, si yo escribo pruebas después del escribir el código (para cada porción pequeña de código, nunca cuando tengo cientos de líneas acumuladas que ya es tarde), las ejecuto con frecuencia y siempre antes de integrar código en el gestor de fuentes, integro las pruebas en la build, me preocupo por que sean rápidas y sobre todo tienen covertura suficiente, etc, etc… ¿No estoy haciendo TDD? En sentido estricto no, pero desde un punto de vista de la filosofía y ventajas que hacer pruebas unitarias aporta, si. Puedo asegurar que, aun escribiendo los test después, estos guían mi desarrollo de manera determinante. Y en un sentido amplio TDD = Desarrollo guiado por pruebas.


Interesantísimo el link que nos ha dejado El Bruno en los comentarios del post de Luis: TDD Proven Effective! Or is it? que viene a dar la misma conclusión que yo trato aquí: no hay grandes diferencias entre escribir pruebas antes o después, pero lo que nadie discute es que hay que escribir pruebas. Se le pedia a Luis responsabilidad y demás, pero la verdadera responsabilidad que tenemos es que todo el mundo sepa de las ventajas de las pruebas unitarias.


Resumiendo escribe pruebas unitarias, eso no es opcional, y luego si quieres llámalas Trinidad

8 comentarios sobre “Le llamaban TDD…”

  1. Efectivamente, eso es a lo que pretendía llegar en mi post, y por cierto, perdona, Rodrigo, si te he metido en medio de todo este malentendido 🙁

  2. No estoy del todo de acuerdo, Rodrigo. Veamos, el TDD se rige por los principios de la XP y, como tal, su base es el uso de las pruebas como agilizador para clarificar el código. Son más una ayuda para desarrollar que una garantía para eliminar fallos.

    Esto se puede ver poco claro ante desarrollos en entornos muy acotados, en los que prácticamente los procesos de Verificación del Software nos garantizan también la robustez del mismo. No obstante, es muy muy muy raro encontrar algo así, y además la efectividad de las pruebas desarrolladas antes que el código dependerá del grado de conocimiento que el desarrollador tenga «a priori» sobre el diseño y la lógica de lo que va a desarrollar.

    De no ser así, se caerá en el fallo que se enumera en el artículo que Bruno nos aportó, el cual sí habla de diferencias entre Test-First y Test-Last, de las cuales para mí la fundamental es la ponderación entre productividad y garantizar calidad mínima…

    Dicho todo esto, es cierto, lo importante es hacer pruebas y estoy de acuerdo contigo en esa libertad que dejas en manos del desarrollador sobre si debe implementar pruebas antes o después. En cierto modo, se trata de una estrategia para ayudarse a sí mismo en su trabajo, pero a nivel de calidad del software no es algo demasiado trascendental ya que las verdaderas pruebas unitarias deberán ser desarrolladas después. Estos dos tipos de pruebas son las únicas que un desarrollador debería realizar sobre su propio código (y en el caso de las segundas, es incluso matizable)

    Un saludo!

  3. Hola Emilio,

    A mí sin duda el framework de testeo que más me gusta es el de Visual Studio, más que nada porque ya viene integrado y por la facilidad para integrar los test en las builds si las haces con MSBuild.

    La verdad es que xUnit está pegando fuerte, y tiene algunas capacidades ques otros frameworks no tienen, pero yo no lo he usado a fondo, en un proyecto de verdad. De los frameworks gratuitos o libres que hay por ahí, el que más he usado es NUnit, y la verdad con resultados buenos. Lo bueno de NUnit es que migrar las pruebas al framework de Visual Studio es muy facil.

    Los atributos que usa xUnit son menos parecidos a los de VS y esto hace que migrar sea más dificil. Hay una interesante tabla comparativa entre los atributos que usan los frameworks de testeo más populares que puede interesar ver:http://www.codeplex.com/xunit/Wiki/View.aspx?title=Comparisons&referringTitle=Home

    Tamibién hay un post de Carlos segura que habla de xUnit: http://geeks.ms/blogs/csegura/archive/2008/02/06/de-la-prueba-al-hecho-xunit.aspx

    Recordar por último que desde VS2008 la capacidad de hacer pruebas unitarias está también en la versión profesional.

    Un saludo!!!

  4. Yo en lo personal creo que el realizar las pruebas antes puede mejorar notablemente el diseño de nuestra aplicación y esto se debe a qué si lo realizamos adecuadamente estaremos probando el dominio de nuestro cliente (por dominó entiendase todo aquello qué tiene que ver con el negocio qué estamos desarrollando) y por lo tanto es muy probable qué cambiemos nuestras clases de manera muy temprana para qué puedan ser incorporadas reglas de negocio, mejorando así nuestro diseños. Por otro lado escribir las pruebas antes nos forzara de manera natural a realizar código qué se pueda probar, qué es uno de los grandes problemas qué se tiene con el código cuando se desarrolla sin tener las pruebas en mente.
    Por el otro lado concuerdo contigo siempre será mejor probar sea como sea, qué simplemente no hacerlo.
    A mi me gusta escribir las pruebas antes y refinarlas posteriormente para alcanzar una mayor cobertura, y cuando por alguna razòn he tenido que escribir el código antes, regreso nuevamente y desarrollo las pruebas correspondientes.
    Te mando muchos saludos y seguimos en contacto

  5. Hola,
    ¿qué diferencias hay entre XUnit y Visual Studio 2005 Team System? ¿cuál es mejor para realizar las pruebas unitarias?

    Muchas gracias 🙂

  6. @LuciaTA: Pues la verdad es que desde un punto de vista únicamente puesto en las pruebas unitarias poca. Los dos frameworks permiten hacer los mismos tipos de pruebas, si que es cierto que el framework de VS esta muy integrado con la herramienta de desarrollo, sin necesidad de instalar nada adicional.

    Además ahora las pruebas unitarias de VS, desde la versión 2008, están disponibles en la versión profesional.

    Un saludo.

Responder a rcorral Cancelar respuesta

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