Citar:

En entornos de producción se trabaja de manera muy diferente que en entornos de desarrollo. Generalmente te pasas el día atendiendo incidencias mas o menos graves y cada vez que corres un script tienes que ser muy consciente de lo que haces. Me refería a que yo nunca he trabajado con pruebas unitarias porque en mi experiencia cuando hay un problema y tienes que hacer un script o una update o algo no hay tiempo para andar haciendo pruebas unitarias ni nada. Simplemente te tomas el tiempo que haga falta para delimitar exactamente la update que quieres hacer y luego la ejecutas. Si tocaste algo que no debías ya llegará otra incidencia en unos dias.

Claro, pero es que las pruebas unitarias son parte del proceso de desarrollo y es impensable usarlas en un sistema en producción. Lo que describes son tareas muy comunes para un administrador de sistemas o de BD.

Citar:

No le quito valor a las pruebas unitarias. Simplemente que yo no las he usado.

No es que yo sea un experto en testing, sólo que si te pones a medir el tiempo que generalmente se invierte en encontrar la causa de un error (durante el desarrollo) y en su corrección, te das cuenta que necesitas buscar una forma más eficiente de hacer las cosas. Por otra parte la única relación respecto del tamaño de la aplicación es probablemente la cantidad de casos de prueba, pero no es que en una aplicación pequeña no sea necesario hacer pruebas unitarias (puedes no hacerlas, pero seguramente el tiempo de desarrollo será mayor).

Correr pruebas automatizadas luego de un cambio o la introducción de una nueva característica te asegura que el sistema sigue funcionando para los casos de prueba que definiste o te permite encontrar más rápidamente los errores y su causa (según si el sistema pasa los casos de prueba o no).

Citar:

Volviendo a mi caso como lo hago yo:
Pongamos que tengo que crear una gestión de empleados. Pues creo el código para altas, bajas y modificaciones de empleados. Luego voy a un formulario de pruebas y creo tres botones: uno para crear un empleado ideal (un insert), otro para borrar un empleado (un delete) y otro para consultar los datos necesarios. Generalmente un simple list donde vuelco los datos que quiero ver.

Entonces meto un usuario y luego lo consulto. Luego me voy a las pruebas y veo lo que he tocado para saber si todo fue bien o solo lo parece.

De manera que mi rutina habitual es hacer la gestión de empleados, mirarla y luego ir a pruebas y mirar. Eso me ahorra mucho tiempo y problemas.

Claro, es lo que te decía. También yo he realizado pruebas de modo similar en mis desarrollos. Pero esto no son pruebas unitarias. Cuando las pruebas las haces de tal modo que puedes repetir su ejecución tantas veces como necesites y en el momento en que lo necesites (por ejemplo,  puedes automatizarlas para que se ejecuten cada vez que se introduce una modificación -lo que requiere generalmente el uso de un sistema de control de versiones-), entonces el valor de la prueba aumenta en gran medida.

===================
Cómo programar con Gambas

Speed Books: informática libre.