Encuesta del mes: ¿Empleas test automáticos en tu proceso de desarrollo de software?

En la encuesta de este mes, casi la mitad de los que han respondido a la impuesta dicen rotundamente "No, nunca", frente a un 8% que dice "Sí, siempre". Y en torno a un 25% parece ser bastante pragmático y ha respondido "Para algunas cosas sí, para otras no".

En el tercer grupo me encuentro yo. Francamente, no todo el software que escribo necesita tener un nivel suficientemente alto de calidad como para realizar la inversión temporal que requieren los test automáticos. Y sí, a priori podríamos decir que con el software cuanto más calidad siempre mejor. El problema es que la calidad tiene un precio: tiempo.  Y, al menos según mi experiencia, no siempre merece la pena hacer esa inversión temporal.

Por otra parte, una buena parte del software que escribo (software de investigación) no tiene una especificación inicial (exagerando un poco, no habría ni información suficiente para hacer test), y sólo una vez se ha desarrollado el software y se ha probado se puede ver si las ideas estaban o no bien enfocadas, y hacia donde hay que redirigirlas. Buena parte de las ideas que se prueban, se acaban desechando. Cuando el proceso de software es tan exploratorio, la inversión de hacer test iniciales para software que es muy probable que se deseche (lo cual también implica desecharlos tests) es demasiado elevada.

Como consecuencia, para los problemas que yo abordo creo que no siempre tiene sentido hacer tests. Y ese es el motivo por los cuales los uso "Para algunas cosas sí, para otras no".

Los que también los usáis "Para algunas cosas sí, para otras no"  ¿qué es lo que hace que no los uséis en todos los proyectos?. Los que nunca los usáis ¿es porque no son adecuados para los problemas que resolvéis, o es más bien la falta de tiempo y de apoyo por parte de la gente que toma las decisiones?. Y los que afirmáis que los usais "Sí, siempre" ¿creéis que todos deberíamos hacer lo mismo que vosotros?