Parece que el artículo de Testing shows the presence of bugs ha generado unos cuantos comentarios

Entre ellos, Gonzalo dice:

Si habeis trabajado con desarrollo en base a tests no entiendo el comentario de que porque se llevan mal con el tiempo, la verdad.
Los tests ahorran muuuucho tiempo, tanto en la fase de depuración y estabilización de un proyecto como a la hora de añadir funcionalidad.
Y otro punto que los hacen críticos, los tests unitarios salvan proyectos que sin ellos estarían abocados al fracaso.

Me doy por aludido, puesto que creo que Gonzalo se refiere al comentario en el que digo:

Testeo y “tiempo razonable” no se suelen llevar bien

Así que en vez de un comentario he pensado que sería mejor poner este tema encima de la mesa, y compartir mis ideas sobre el testeo.

Realmente a lo que me refería es que muchas veces no es posible hacer un buen testeo o un testeo exhaustivo de una determinada funcionalidad en un tiempo razonable.

Mi opinión es que hacer más o menos tests depende siempre del tipo de proyecto. Por poner dos casos extremos, no es lo mismo hacerte un miniprograma para ti, que por ejemplo renombre todos los archivos de un directorio usando algún tipo de patrón, que por ejemplo hacer un programa que va a controlar la trayectoria de un misil.

No sólo depende del tipo de proyecto si no también de los plazos del proyecto y de los recursos con los que se cuente. No es lo mismo un equipo de un desarrollador, que un equipo con 5. Tampoco es lo mismo disponer de 7 meses para hacer un parser de XML, que disponer de 2.

Hay muchos elementos que influyen.

Volviendo a la discusión anterior, sobre que tests y tiempo razonable no se llevan bien, básicamente esto significa que si tu proyecto es de andar por casa, tus recursos son limitados o tu tiempo es escaso, probablemente puedas y debas posponer algunos tests.

Estoy de acuerdo con Gonzalo con que los tests traen muchos beneficios, pero esos beneficios, desde mi punto de vista son a medio y largo plazo. A corto plazo los tests beneficiosos son aquellos que te permiten ir desarrollando la aplicación y probando lo que tu crees que van a ser los casos más comunes.

Soy partidario de hacer tests desde el primer momento, de  hecho, en otro comentario mío se puede leer:

Mi opinión (al menos es lo que yo hago) es que hay que ir haciendo tests para probar las cosas conforme se desarrolle
[...]
cuando se encuentra un bug (o bien por uno mismo, o por un usuario), mi punto de vista es que hay que añadir un test-case que lo reproduzca

Se pueden escribir páginas y páginas sobre el testeo de software, sobre metodologias de programación, sobre si hay o no que llegar al 100% de cobertura de código… el caso es que escribir un buen artículo que cubra todos estos aspectos en un tiempo razonable, tampoco lo veo posible…

¿Haceis tests a menudo? ¿lo considerais perder el tiempo?

¿Cuales son vuestras prácticas habituales?

Como siempre, vuestras ideas y opiniones son bienvenidas en los comentarios y/o posts en vuestros respectivos blogs.

Trackback URL

black box, ingenieria de software, opinion, Programacion, smoke tests, tests, tests unitarios, white tests