Cuantos de ustedes hacen Unit Testing?

[mamcx]

Bueno, como saben tal vez, estoy desarrollando un proyecto open source llamado MUTIS. Es el primer proyecto que he desarrollado por mi empresa y a todo el gusto mio !

Pero más que nada he visto como el emplear desde el principio los unit testing ha catapultado la productividad y calidad del mismo, a pesar que no es el tipo de desarrollo al cual estoy acostumbrado... y me hace preguntar cuantos estan enterados que es unit testing y mejor aún, cuantos lo usan regularmente?

Teniendo en cuenta que las herramientas son gratuitas (e incluso vienen listas en Delphi 2005) y hacer un test requiere el mismo tiempo que preparar una prueba de escritorio pero con la ventaja de que queda guardado para despues...

Escribí un artículo mencionando algunas ventajas, pero me gustaria conocer la experiencia de los foreros de Club Delphi...

[mamcx]

Para los que respondieron/piensan de acuerdo al punto 3 de la encuesta, que problemas o inconvenientes le ven?

No es que sea sencillo empezar con esto, mas bien que tambien me dio dificultar arrancar y de pronto puedo aportar alguna experiencia...

[[Lepe]]

Hola mamcx, antes de nada gracias por la info, la verdad es que ni siquiera sabía que existía tal utilidad. He votado por la primera opción

Recien la acabo de bajar y probar. En los ejemplos que trae, no hay mucho código, así que al principio lo ví como un "TODO LIST", sin embargo, leyendo la documentación, se usa el programa test antes de implementar una clase.

El problema que le veo, es que los fallos surgen porque no los hemos controlado correctamente, o no nos hemos dado cuenta de un posible escenario, en este sentido, no nos ayuda mucho tener la clase TEST.

Si tenemos un programa ya hecho, y se realizan modificaciones, ahora si le veo sentido al programa TEST, ya que verifica el nuevo código para las condiciones anteriores.

Lo que me ha gustado enormemente es tener 2 programas independientes, sin que uno afecte al otro. Hasta ahora, añadía a mi código:

frmdebug.anade(['nombre variable'], [valor de la variable]);

Para no andar con puntos de ruptura. Una vez depurado, quitaba las lineas de debug.

Lo que no me ha gustado, es tener que mantener el programa TEST, es decir, si elimino métodos de una clase, tendría que actualizar el programa TEST.

Consejo: Para todo aquel que se baje Dunit, que se baje el pluging "Wizard".

[mamcx]

Lo que no me ha gustado, es tener que mantener el programa TEST, es decir, si elimino métodos de una clase, tendría que actualizar el programa TEST.

Creelo o no es una ventaja... Porque piensas en eso? Ese es un efecto colateral beneficioso de tener una suite de test... Simple y llanamente corrobora que tan testeable es el codigo actual, si es modular, si esta separado la GUI de la logica de negocios del acceso a datos y de las utilerias.

Por otro lado, al menos cuando se estan creando las clases al principio, el pensar en mantener dos sistemas ayuda en ser mas cuidadoso y seguir un buen estilo de desarrollo, el estilo KISS (siglas en ingles para "Mantenlo simple, estupido!") y ayuda a limitarse a hacer solo lo necesario. Y eliminar caracterisiticas / codigo es una forma efectiva de cumplir con las metas.

Por otro lado... igual si alteras el contrato de una clase, no toca actualizar todo el resto del codigo, como la parte de GUI? Ahora la ventaja es que el cambio primero se hace en ambiente de pruebas y solo al FINAL se mueve a "produccion".

Esa es una de las mejores practicas para hacer OO:

- Hacer clases modulares y tan independientes como se pueda
- Que estas clases tengan metodos efectivos de comunicacion
- Que se puedan desprender las unas de las otras sin afectar severamente el funcionamiento de estas
- Mantener los contratos este clases (la interface) estable en el tiempo, lo que implica sentarse 2 minutos mas a pensar en las consecuencias de hacerlo "rapido y sucio" en vez de "rapido y efectivo".

Espero que te sirva tu investigacion...

[mamcx]

Me encontre esta informacion para aquellos que estan empezando (ingles):

http://bdn.borland.com/article/image...DUnitMain.html

[DarKraZY]

No he votado, ya que me encuentro dentro del grupo de "Lo estoy empezando a descubrir y sí que lo veo útil."

Llevaba un tiempo investigándolo. Y desde fuera, al principio, parecía muy difícil o no le veía el resultado.

En cuanto te metes en la OOP (o POO) te das cuenta de la importancia de la modularidad, cohesión, reutilidad... de todo el código fuente. Y a partir de ahí he visto más de cerca la necesidad de realizar pruebas, y además guardarlas.

Hoy por fin me lo he instalado definitivamente, me he leído el manual, he visto por encima los tests... y todo empieza a estar más claro.

Le veo una gran utilidad ya que te permite:

• Guardar las pruebas
• Lógicamente, probar tantas veces como desees
• Al hacer antes las pruebas, tener más claras las estructuras de las clases
• Tener más seguridad en el propio código

[jmariano]

Antes de nada quiero agradecer a mamcx por comentar esta gran herramienta!

Yo, al igual que DarKraZY, no he votado porque pertenezco también al grupo de "Lo estoy empezando a descubrir y sí que lo veo útil." (creo que faltaría esta opción en el test).

La verdad es que hacía tiempo que buscaba una herramienta que me permitiera probar mis clases de una forma sencilla y organizada, sin tener que estar con puntos de ruptura, mensajes en el código, etc. (a parte de que el depurador de Delphi no muchas veces acierta donde está el problema...). Ahora, eso sí, como dice Lepe, usad el "Wizard" para "DUnit" porque, si no, se vuelve muy tedioso el crear las clases tests (con el asistente en dos segundos tendreis todo el esqueleto de la clase mas el programa TEST).

saludos!