[Artículo] Unit Testing: Qué es y cómo se usa en VFP 9

[Fernando D. Bozzo]

Hola:

Bueno, lo prometido, espero que lo encuentren útil:

http://fdbozzo.blogspot.com/2014/07/unit-testing-que-es-y-como-se-usa-en.html


Saludos!

[César Pistiner]

Si bien ya te lo comenté en Google+ te lo repito, buen artículo Fernando, de seguro va a ser de mucha utilidad para los que quieran comenzar con test unitarios!

Gracias,

César

[Victor Espina]

Excelente.  Para los que nunca han trabajado con esta tecnica, les digo:

SI, es mas trabajo

SI, alarga el tiempo de desarrollo

SI, es un fastidio

Pero lo que se obtiene justifica con creces el tiempo extra:

Sistemas mas estables = Menos llamadas de soporte por "garantia" = menos costos

Clientes mas satisfechos

Mejor reputacion como empresa / programador

Usar TestUnits te obliga a usar un mejor diseno, mas modular y encapsulado, al momento de programar

Modular-Encapsulado = Mayor reusabilidad

Saludos

Victor Espina

[César Pistiner]

Hola Victor,

a mi forma de ver las cosas... 

NO es mas trabajo si evaluas todo el conjunto ya que el código que te queda es muchísimo más mantenible y fácil de meter cambios.

NO alarga el tiempo de desarrollo por lo mencionado anteriormente.

NO es un fastidio... una vez que empezas, hasta te diría que cuesta escribir código sin que tenga un test...

Pero coincido con vos en que la primera impresión es esa que mencionas :) 

Saludos,

César

[Fernando D. Bozzo]

Agrego mi opinión, ya que entiendo lo que dice Víctor y lo que decís vos también :-)

El problema tiene bastante de "percepción":

Obviamente que los tiempos de desarrollo haciendo tests son superiores a los tiempos de desarrollo sin hacerlos. En mi caso particular, cuando comencé a usarlos me costó bastante aprender cómo hacer un buen caso de prueba, y mis tiempos de desarrollo se duplicaban en algunos casos, dependiendo de la complejidad de lo que quisiera probar. Pero en mi caso hay que contar con que soy bastante detallista y me gusta hacerlo lo mejor posible, y si luego de hacerlo veo que se puede mejorar, voy y lo mejoro, que para mí es parte del proceso de refactorización. Hasta aquí, la percepción es como dice Víctor.

Pero luego está la parte que nadie cuenta, y que realmente es la que se lleva muchas veces el mayor tiempo, que es la de las pruebas manuales, donde hay de 2 tipos: las pruebas manuales que se pueden automatizar y las que no.

Dentro de las pruebas manuales que no se pueden automatizar (que suelen ser los tests de integración, o sea donde se prueba como interacciona todo el conjunto), pues no hay salida, deben seguirse haciendo manualmente, aunque programas como el Sikuli, que comenté antes, pueden ayudar en cierta medida.

Dentro de las pruebas manuales que se pueden automatizar, es donde se puede sacar mayor provecho, ya que en general toda prueba requiere la comprobación de Interfaz por un lado y de resultados por el otro, aunque al principio no nos demos cuenta y verifiquemos todo como una unidad, y justamente la parte de comprobación de resultados es la que suele poder automatizarse fácilmente, como el ejemplo del cálculo del PVP que puse en el artículo.

Si contamos esta parte de los tiempos de prueba (resultados, cálculos, totales, datos, etc) y los separamos de lo que es estrictamente Interfaz (controles, refresco, enabled/disabled, click aquí o allá) éstas suelen ser la mayor parte de los tiempos de pruebas totales, que en general suelen ser horas o días (días de 8 hs), dependiendo de la complejidad del programa o sistema, y que es a lo que me refería en el artículo.

Por eso, al automatizar esta parte de las pruebas, que implica programar casos de prueba, es donde cambia la percepción de que el tiempo de desarrollo sube, pero por otro lado el tiempo de pruebas baja bastante, y cuando hay que repetir esas pruebas, la bajada de tiempos ya es abismal, porque los casos de prueba simplemente se vuelven a ejecutar y no hay que programarlos otra vez, en contraste con las pruebas manuales que deben repetirse al completo.
Esta es una de las partes que nadie suele medir, los tiempos de pruebas.

Luego está la otra parte que nadie mide, y es la de los tiempos requeridos en resolver las incidencias. ¿Por qué? Porque nadie cuenta con ella, y todos creen que si las pruebas manuales fueron bien, ya todo está bien y no hay de qué preocuparse. Pero luego llegan las incidencias inesperadas, esas que no debían ocurrir, y ya no se mide, "se corre" para solucionarlas cuanto antes, lo que suele implicar todas o algunas de estas fases (cada uno adapte a su caso):

1. El cliente detecta un fallo en sus pruebas y las anota (tiempo de pruebas perdido, porque deberá repetirlas más adelante)
2. Al terminar las pruebas, el cliente reporta los fallos encontrados (más tiempo, al teléfono o redactando el documento con los detalles)
3. El gestor recibe los fallos y los comunica al equipo (tiempos de gestión)
4. El equipo de desarrollo (o el único desarrollador) recibe los fallos y:
1. Intenta entender lo que quiso decir el cliente (tiempo de "decodificación" e "interpretación" del documento, si lo hay)
2. Intenta reproducir los fallos en su PC (tiempo de pruebas hasta dar con el caso específico)
3. Encuentra el fallo y lo soluciona (tiempo de programación y pruebas manuales nuevamente)
4. Genera una nueva versión y la vuelve a entregar al cliente (tiempo de entrega y/o despliegue)
5. El gestor avisa al cliente de que tiene el programa arreglado (tiempo de gestión)
6. El cliente vuelve a realizar sus pruebas (tiempo de pruebas manuales, nuevamente)
7. Un punto de mala imagen para el proveedor (coste de imagen y confianza)
   

Esto, básicamente, es la forma en que suele ocurrir en una empresa grande, en un trato directo con el cliente o PYME seguramente se pueden quitar algunos o varios pasos, pero algunos son inamovibles.

Esta es la segunda parte de los tiempos que nadie suele contar, y por eso queda la sensación de que los tiempos de desarrollo suben, que es cierto porque se invirtió tiempo en hacer tests, pero los tiempos de incidencias y pruebas bajan de manera notable, y agreguemos el tiempo de desarrollo del arreglo de la incidencia, pero como en esta fase todos están corriendo por "solucionar las incidencias" que son muy importantes, nadie tiene tiempo de contar cuánto tiempo perdido se gastó. (Recalco lo que subrayé de tiempo invertido y tiempo perdido)


Respecto a que sea un fastidio, depende del tipo de casos de prueba que te toquen hacer. Algunos son fáciles y rápidos, otros son entretenidos o creativos, y en otros a veces te tenés que romper la cabeza para lograr unos buenos casos de prueba, que son inherentemente complejos y que querés intentar simplificar para que luego sean fáciles de mantener. Pero en todo caso, una vez los terminaste podés descansar mucho más tranquilo

Y a estas dos partes de los tiempos sin contar es a lo que se refiere César cuando habla de "evaluar todo el conjunto".


Y con este supero interesante debate me doy cuenta de que puedo agregar algo de esto al artículo :-)

Saludos.-

[César Pistiner]

Fernando, 

Fuaaaa!!! Si bien pienso muy similar a vos, jamás podría explicarlo como lo haces... mostro!!

Y si, seguí alimentando ese artículo que de mucho va a servirle a más de uno.

Saludos,

César

[Jose Mario]

bueno para la escritura fernando

tiene dotes de escritor

[Fernando D. Bozzo]

Gracias Mario! Lo que realmente me motiva es cuando me entero por ustedes de que les resultó útil o claro.

Un abrazo!

[Victor Espina]

Excelente Fernando. Sin desperdicio. Solo queria agregar que en esto, como en otras tecnicas, lo dificil es intentarlo la primera vez y luego interiorizar el concepto.    Es como el tema de la programacion en "n-capas":  si, da mas trabajo muchas veces que los enfoques monoliticos tradicionales, pero las ventajas son muchas. El truco es incorporarlo dentro de tus paradigmas de forma tal que ya no tengas que DECIDIR si hacerlo asi o no, sino que de una vez ya disenas las cosas pensando en terminos de n-capas.  

Lo mismo es con esto del test unit.  Por eso decia que una gran ventaja de implementar esto en nuestro proceso de desarrollo es que nos obliga a disenar mejor el software, pues mientras mas encapsulado y autosuficiente sea un componente, mas facil sera crear un caso de prueba para el mismo.  Y coincido 100% contigo:  muchas veces la rentabilidad de un proyecto se va en el soporte post-instalacion, pues los usuarios son PESIMOS para reportar errores de forma confiable o util, y eso nos lleva a invertir muchisimo tiempo solo en entender el problema o incluso reproducirlo a voluntad para poder resolverlo.  

Saludos

Victor Espina

[Fernando D. Bozzo]

Gracias Víctor!

Y coincido con vos en lo de trabajar en capas. Ambas cosas al final se potencian, porque separar en capas te ayuda a modularizar, modularizar te facilita mucho crear tests más expecíficos, prácticos y fáciles de hacer, los tests a su vez te permiten encontrar formas de parametrizar y modularizar mejor, lo te permite refactorizar con más seguridad, ya que contás con los tests para verificar lo que refactorizaste, y así, una cosa ayuda a la otra.

La refactorización es otra de las cosas que muchos Foxeros no conocen bien, y que forma parte de las buenas prácticas de cualquier lenguaje.

Pero bueno, lo importante es sacar todas estas técnicas, mostrarlas y explicarlas para que cada uno pueda ir viendo, probando y sacando sus conclusiones.


Saludos!

[Rafael Morales]

Se ve muy interesante. Gracias Fernando.

--
Rafael Morales

[collinssco...@gmail.com]

¿Necesita un préstamo urgente para pagar sus facturas? En caso afirmativo en contacto con nosotros a través de leolobito...@hotmail.com

[Luis Mata Figueroa]

Y este?????? sera el billete negro...

[Fernando D. Bozzo]

Son bots, no usuarios, que andan recorriendo los foros metiendo spam en algunas conversaciones.

Es mejor no prestarles atención.

El 15 de julio de 2014, 18:25, Luis Mata Figueroa <lm...@cclf.com.pe> escribió:

Y este?????? sera el billete negro...

[Mario Oviedo]

https://www.youtube.com/watch?v=ixy0ZSyZhuM#t=109

[Mario Oviedo]

no sabia que era bots