Mucho se ha dicho sobre la importancia de hacer unit testing.
Sin embargo todavia muchos programadores desconocen las ventajas que reportan tener un conjunto automatizado de pruebas....
O tal vez parece muy complicado.
Es dificil enseñarle nuevos trucos a un perro viejo, pero este es uno que vale la pena. En primer lugar, no hay que invertir dinero, se puede conseguir las herramientas de Unit Testing de forma gratuita.
Con Delphi, se usa DUnit (el cual esta integrado dentro de Delphi 2005 y superior).
En la página de DUnit hay tutoriales sobre como se hace un test. ¿En esencia? Es simplemente hacer una prueba de escritorio, pero en vez de escribir sobre el papel se escribe código real, el cual queda guardado para futuras pruebas.
Tambien se puede ver como almacenar para la posteridad una sesión de depuracion...
Estas son algunas que personalmente he observado:
Enfoca el esfuerzo de desarrollo en hacer código sin errores (al menos sin los obvios). El punto central de hacer Test es que el esfuerzo se pone en mantener el código funcionando correctamente y en sostenerlo de forma estable en el tiempo. Sin hacer test automaticos, el esfuerzo se diluye entre hacer nueva funcionalidad (incluso aunque sea innecesario) y en posponer la resolución de los problemas.
Mayor confianza en el código. Es un sintoma muy común el "temor" a tocar el código fuente, porque al efectuar un cambio, este puede tener efectos colaterales y dañar funcionalidad que estaba trabajando bien antes.
El tener una suite de pruebas permite detectar a tiempo cualquier efecto colaterar y permite entrar con confianza a hacer cambios internos (como por ejemplo, arreglar un código que no se entiende muy bien y es difícil de mantener) con la seguridad de que el resultado final seguira siendo correcto.
El punto es, es horrible testear código así. Por lo tanto, en el esfuerzo de hacer código/clases fáciles de testear como efecto secundario se fuerza a separar las tareas y en hacer código más modular, y más fácil testear = más fácil de entender = más fácil de mantener = código más solido.
Al crear los esqueletos de que pruebas hay que hacer, es como tener una lista de tareas que se marcan completas cuando el código pase correctamente las pruebas.
Por ejemplo, supongamos que hay que hacer un software de facturación. En este tipo de software, hay que hacer procesos como aumentar/disminuir el inventario, devolver compras, dividir los pagos en cuotas y cosas asi. Hacer las pruebas ANTES del código es simplemente hacer esto:
procedure TestAumentarInventario
begin
CheckTrue(False);
end;
procedure TestDisminuirInventario
begin
CheckTrue(False);
end;
procedure TestDevolverCompra
begin
CheckTrue(False);
end;
Se usa CheckTrue(False); para marcar que aún no se ha realizado la prueba de esa funcionalidad.
Asi, que ahora hay una lista de 3 tareas... a eso me refiero con mantener el enfoque.
Ahora DUnit nos va a informar que nos faltan por completar 3 test, y nosostros entonces vamos a hacer que esos test pasen bien. Si adicionalmente llenamos en blanco el resto de la funcionalidad de nuestro software vamos a poder hacer estimativos reales sobre cuanto nos va a costar terminar el programa... y los programadores en vez de llegar al trabajo preguntandose ¿y que hago ahora? y mientras lo piensan se ponen a navegar por Internet, van a tener una lista de tareas por hacer, que les muestra su progreso y que los mantiene MOTIVADOS.
Asi que si no estan haciendo unit testing empiezen ya! Bajense DUnit y lean un poco sobre este tema y miren los tutoriales.