Usar la metodología TDD con Criterio

Cuando aplicamos la metodología TDD (Test-Driven Development) a menudo caemos en los dos extremos, al comienzo del proyecto aplicamos TDD a casi todas nuestras clases y métodos. Luego, a medida que se acerca la fecha de entrega nos damos cuenta que estamos atrasados, nos abrumamos y dejamos de lado el TDD.

Como casi todo (o todo!!!) en la vida, la clave es el equilibrio, buscar el punto medio, y este punto medio nos lo da nuestro criterio.

¿Qué criterios aplicar?

Leyendo el blog de http://calenlegaspi.blogspot.com/ coincido con el, para encontrar el punto medio podemos hacernos las siguientes preguntas.

1.- ¿Que tan probable es que este escenario(clases y métodos) presente incidencias?

2.- ¿Qué tan critico es este escenario?

3.- Las clases son complejas, requiero retroalimentación

¿Que tan probable es que este escenario(clases y métodos) presente incidencias?

Obviamente, no deberíamos probar cosas tan simples como los getters y setters, referencias nulas, números positivos, etc. Estás validaciones se dan por hecho.

Si en una primera o en una segunda revisión (si señor, hay que hacer revisiones) del código del escenario te asegura que funcionará, entonces no necesitas una prueba unitaria.

Muy importante, tu puedes incrementar la cantidad de código que no necesiten de pruebas unitarias, esto lo consigues usando librerías de terceros de alta reputación, es código ya probado y con un madurez importante.

Es por eso que más pruebas no necesariamente significa una mejor calidad del software. De hecho, se obtiene más calidad de software si re-usas código probado a implementar tu propio código.

Las clases son complejas, requiero retroalimentación
Aplicar TDD me permite recibir retroalimentación de como trabajaría mi clase en tiempo de ejecución, que tan fácil y cómodo será su uso o integración y validar que la clase o clases cumplan con la funcionalidad esperada.