¿Cuál es la diferencia entre ser inteligente o ser tonto? Creo que podría resumirse en dos cosas: qué tan lejos en el futuro podés pensar, y qué tan rápido podés generar este pensamiento. Cuando alguien juega ajedrez, o poker, sus habilidades están determinadas por cuántas movidas puede pensar por adelantado. Cuánta historia pueden recordar, y así planificar el siguiente movimiento.

En el desarrollo de software, ¿qué tan lejos podés mirar? ¿Estás usando prácticas destructivas porque estás muy ocupado "terminando el trabajo"? ¿Estás ignorando buenas prácticas que podrían ahorrarte tiempo?

Imaginemos el siguiente escenario: estamos codificando el test para guardar un cliente, y necesitamos que ya exista en la base de datos la empresa a la cual pertenence. ¿Qué hacemos? Una primera solución rápida es contar con datos de tests ya existentes en la base de datos, y confiar en que dichos datos sirvan para nuestro test (o, si no alcanzan, agregar los datos de tests necesarios a la base). Y sin embargo... hacer esto es el comienzo de graves problemas.

En un artículo anterior sobre la calidad interna y externa del software plantee la importancia de la testeabilidad para la calidad de un sistema. Reforzando el mensaje: cuando se aumenta la testeabilidad del software, mejoras directamente  tu arquitectura y tu diseño. Desarrollar sin pruebas unitarias automatizadas y sin pruebas de aceptación es simplemente, construir código legado desde el momento cero!

Al comenzar a desarrollar usando la técnica de Desarrollo Guiado por Tests (TDD - Test Driven Development) es común preguntarse qué hacer con los métodos privados. ¿Cómo se deben probar? ¿Qué ocurre con estos métodos que no podemos acceder directamente desde las pruebas unitarias?

Si realmente estamos haciendo TDD, los métodos privados tienen cobertura garantizada. Cuando el diseño y la implementación en el código se guia a partir de las pruebas unitarias, ningún método se crea como privado. En cambio, los métodos privados se extraen (el refactor) de un método público ya existente.

No sé. A veces siento que algunas personas venden mal todas las excelentes ventajas del Desarrollo Guiado por Pruebas (TDD) y la Programación de a Pares (PP). Es que muchos agilistas exponen este argumento: al hacer TDD y PP se incrementa la calidad, así que aunque la productividad disminuya,tenemos la conciencia tranquila de que fuimos buenos ciudadanos del mundo del software.

¡Mentira!. No sólo no es verdad que se pueda cambiar la calidad interna por más características, sino que es justamente lo contrario: mientrás más productivdad se busca, más alta debe ser la calidad interna.

La prueba unitaria es sumamente importante y no hay ninguna duda que la práctica del TDD ayuda a escribir código bien estructurado, con bajo nivel de defecto.

Sin embargo, un equipo que realiza exclusivamente TDD puede tener otros problemas. De hecho, ¿hasta qué punto hacer TDD, que está a nivel de pruebas unitarias, permite visualizar el comportamiento del sistema?

Crear un entorno para realizar correctamente TDD no es una tarea facil. Tenemos que pensar en la Integración Continua (y el servidor que la soportará), en el script de construcción del proyecto, en la ejecución y publicación de las pruebas unitarias, en el sistema de versionado de fuentes...

El excelente artículo Montando un entorno de integración continua con Hudson + Ant + SVN + NetBeans el autor nos cuenta cómo utilizar estas herramientas para armar un entorno sencillo para comenzar con a trabajar con TDD.

Crear un entorno para realizar correctamente TDD no es una tarea facil. Tenemos que pensar en la Integración Continua (y el servidor que la soportará), en el script de construcción del proyecto, en la ejecución y publicación de las pruebas unitarias, informes de Cobertura de código, y más...

En la nota anterior, vimos cómo crear un entorno TDD usando Hudson, NetBeans, Ant y SVN. En esta excelente segunda parte, veremos cómo usar Cobertura junto a NetBeans y Hudson, para terminar de crear un entorno TDD completo, con informes de cobertura, gráficos y más.

Según un estudio reciente, el uso de Test Driven Development (TDD) incrementa el tiempo de codificación en un 15-30%, y resulta en un 40-90% menos de defectos. El estudio se hizo en 4 equipos de desarrollo diferentes (1 de IBM y 3 de Microsoft). Esto confirma lo que cualquier practicante de TDD te puede decir: se gasta un poquito más de tiempo en escribir las pruebas, pero la calidad del código resultante es muy superior.

Quien ha utilizado el desarrollo orientado por las pruebas (TDD) sabe como está directamente relacionado con el diseño del código. Un diseño testeable (comprobable) normalmente es un diseño desacoplado y reutilizable. TDD es mucho más sobre diseño que sobre pruebas.

TDD es una práctica que envuelve el desarrollo en su conjunto. Especialmente el diseño. Algunos dicen que su última letra, la letra D, debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.

Un estudio publicado por la Empirical Software Engineering demuestra que TDD puede ser aplicado en distintos dominios y puede reducir de forma significativa la cantidad de defectos del software sin reducir la productividad de los equipos de desarrollo. El estudio compara a 4 proyectos en IBM y Microsoft que usaron TDD contra proyectos similares que no no usaron TDD.

El Desarrollo Guiado por Pruebas (o TDD) se suele describir como un ciclo de rojo-verde-refactor, que se repite continuamente, para ir agregando nuevas características o arreglar bugs. La siguiente lista de comprobación que comparte Giorgio Sironi contiene un grupo de preguntas que deberíamos hacernos a nosotros mismos mientras avanzamos por las fases de TDD, para no olvidarnos de la esencia de esta técnica.

La edición de enero-febrero 2010 de la revista Harvard Business Review publicó un estudio muy interesante sobre la motivación de los trabajadores. Y, si lo analizamos un poco, veremos que el estudio nos explica porqué TDD funciona tan bien para el desarrollo de software.

La práctica de Desarrollo Guiado por Pruebas (TDD) nos hace encarar la programación con un nuevo enfoque, pensando y escribiendo primero las pruebas y luego la implementación. Pero además de escribir primero la prueba, podemos avanzar aún más: hacer que las pruebas pasen exitosamente lo antes posible, incluso aunque esto signifique escribir código "de mentira" para hacer pasar a la prueba en cuestión.

Escribo mi código con TDD (Test-Driven Development, o Desarrollo Guiado por Pruebas) casi desde mis inicios como desarrollador de software, y a lo largo del tiempo he visto los beneficios de hacerlo, y las consecuencias de no hacerlo. Y de esa experiencia, descubrí que hay varios mitos alrededor de TDD... y algunas verdades.

Hay muchísimas prácticas que podemos adoptar para mejorar la calidad de nuestro código. ¿Por dónde empezar? ¿Existe una lista única y completa? En este artículo veremos un pequeño listado de buenas prácticas, que nos pueden ayudar a comenzar ese largo camino que implica trabajar con más profesionalismo, mejorando los productos que desarrollamos.

Muchas personas confunden a las "metodologías de probar primero" con TDD; es bastante común escuchar comentarios como "la esencia de TDD es escribir primero las pruebas". Y están completamente equivocados, ya que estas afirmaciones no describen para nada a TDD, y sólo hablan sobre el desarrollo con pruebas primero.