Comunidad Gambas-es

¿Alguien está haciendo pruebas unitarias en sus desarrollos? Si es así, ¿alguna idea sobre cómo facilitar esta tarea?

Define "pruebas unitarias", que uno ya no sabe ni qué idioma habla... jejeje

Pruebas unitarias

El tipo de prueba que se realiza habitualmente con la ayuda de un frameworks como Junit (cuando se programa en Java obviamente).

No hay respuesta, asumo entonces que nadie hace pruebas unitarias... hummmm mala cosa.

Yo siempre he trabajado en entornos de producción donde lógicamente no se hacen pruebas unitarias y las aplicacaciones que hago son pequeñas para necesitar esas técnicas sin embargo las hago un poco a mi modo.

Yo cada vez que creo una entidad nueva (por ejemplo empleados) primero hago el código de empleados para altas, bajas y modificaciones. Cuando lo tengo hecho me voy al formulario de pruebas que tengo para estas cosas añado un botón de empleados y allí pongo un botón que borra todo lo tocó el proceso de meter o modificar empleados, otro que agrega un empleado de prueba y otro que me vuelca una vista con los datos adecuados y los cruces correspondientes.

Suele ser muy poquito código, rara vez mas de veinte lineas por entidad, pero con ello me aseguro que todo queda bien. Ese formulario de prueba se queda siempre en mi aplicación según va creciendo y con él siempre tengo la posibilidad de crear una situación ideal para probar algo o bien meter un empleado ideal con un contrato ideal, etc.

En mi caso las pruebas unitarias y las pruebas de integración son matar moscas a cañonazos.

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?

Buff... yo lo arreglo, lo pruebo y le digo al usuario: "Pruébalo, que está aún un poco verde".

El tío lo prueba, le saca los fallos y me los manda. Si luego casca le digo: "¡Pero Hombre! ¿No te dije que lo probaras bien?"

Es lo que pasa cuando no hay tiempo para pruebas... pero funciona

(Eso sí a mí me pagan lo mismo falle o no, que si no, otro gallo cantaría...)

Saludos

Citar:

Buff... yo lo arreglo, lo pruebo y le digo al usuario: "Pruébalo, que está aún un poco verde".

ja ja ja yo no me puedo permitir ese lujo.

Citar:

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?

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.

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

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.

Shordi parece que tus clientes se han portado muy bien contigo (o tal vez no seas tú quien recibe las quejas de forma directa).

Aquí en Argentina lo más común es que cuando tu programa falla por segunda vez el cliente te llame por teléfono para acordarse hasta de tu madre.

Citar:

Es lo que pasa cuando no hay tiempo para pruebas... pero funciona

Como si fueras a comprar pan, encontraras que está crudo y al reclamarle al panadero te dijera que no tuvo tiempo para cocerlo.

Citar:

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.

Veo que Soplo utiliza mi mismo sistema...

Citar:

Shordi parece que tus clientes se han portado muy bien contigo (o tal vez no seas tú quien recibe las quejas de forma directa).

Aquí en Argentina lo más común es que cuando tu programa falla por segunda vez el cliente te llame por teléfono para acordarse hasta de tu madre.

Sí que las recibo sí, pero trabajo para la administración, y eso en españa es garantía de que "no passsa naaaadaaaaa..."
Es decir, los clientes tampoco tienen mucha prisa..