Gracias Soplo por la información.
No comprendí esto:
Citar:
Yo siempre he trabajado en entornos de producción donde lógicamente no se hacen pruebas unitarias...
Obviamente no se deben correr pruebas contra una aplicación que está en producción ¿a eso te referías?
Por otra parte discrepo contigo en el valor y utilidad de las pruebas unitarias. No me parece que sean menos útiles en aplicaciones pequeñas, sino que para una aplicación pequeña los casos de prueba generalmente serán muchos menos y esa debería ser toda la diferencia.
Respecto a BD lo que yo hago es volcar casos de prueba a scripts SQL, para inserción, eliminación, modificación y consulta, y los corro contra la BD.
Respecto de la aplicación frontal, a veces he volcado casos de prueba en rutinas que son llamadas al pulsar un botón de un formulario. Sin embargo, las pruebas deberían ser automatizadas y también debería ser posible correrlas desde fuera del programa que se está desarrollando.
Lo que intento es aplicar la técnica "testing first" en mis desarrollos en
gambas para intentar disminuir todo lo que pueda la necesidad de usar el depurador integrado, para no usarla como una herramienta central, sino como una herramienta de asistencia para la inspección del código (cuando esto fuera necesario). Pero para ello debo determinar un procedimiento a seguir para escribir y ejecutar las pruebas.
No me refiero a qué cosas probar (eso ya es otro tema) sino a cómo escribir las pruebas: ¿como una clase dentro del programa? ¿como una clase escrita independientemente y exportada? (esta última parece una mejor idea).
Pero, ¿cómo llamo desde una clase externa a los métodos de las clases del programa que quiero probar? ¿debería exportar también las clases del programa que estoy sometiendo a pruebas? ¿hay otro modo de hacerlo?
Foro 
Albacete
