Comments on Abstracta Blog: Test cases resistentes a parametrizaciones

David, tal como decís, GXtest es más para pruebas ...

2009-07-08T10:36:24.877-07:00

David, tal como decís, GXtest es más para pruebas de sistema (todo el sistema integrado), a no ser casos específicos, los módulos a usar sería deseable que sean los reales y no stubs ni mocks, pero cada caso es particular.

El ejemplo que pusiste está bueno, pero es sólo para validaciones, nosotros estamos poniendo más énfasis en lo que es el flujo, pero el ejemplo sirve también, gracias!

La idea de dar una interfaz más simple al usuario (tester) para obtener los datos de prueba está buena, pero no siempre se tiene la posibilidad de "navegar" o "consultar" la kb de desarrollo, y tal vez sea deseable que se tenga la posibilidad de delegar la tarea. Lo mejor es dar las dos posibilidades, así que lo tendremos en cuenta.

El tema de Data Providers, y los tipos estructurados por ahora no los estamos manejando, la idea es que los ProcGX devuelvan tipos de datos simples para que sean cargados en variables de GXtest que son del tipo entero o string. Supongo que sería interesante a futuro avanzar también en ese sentido.

Saludos David! y gracias!

Simon!! gracias por el comentario! En realidad el...

2009-07-08T10:28:44.975-07:00

Simon!! gracias por el comentario!

En realidad el tema de generación de casos de prueba en forma automática a partir de modelos de mayor abstracción lo estamos dejando para más adelante, eso aplica cuando tenés la base bien estable, o sea, el primer problema es poder hacerlos a mano, de forma tal que sean mantenibles, que funcionen, bien enganchados a la KB, etc...por ahora estamos atacando el problema por ahi, lo que vos decís queda para luego de tener esto bien firme.

A lo que nos referimos es cómo diseñar manualmente los Test cases, cómo pensarlos ... es algo más de metodología, no? El tema también pasa por las facilidades que te da la herramienta para esto, y por eso también lo quisimos destacar.

gracias por el comment
salutes!!!

PD: espero que vaya todo bien de bien por Alemania, vas a ser nuestro representante allá (digo, si ves a alguno que use Genexus jeje)

Una ventaja de la opcion 1 .. es que los test-case...

2009-07-08T10:25:19.140-07:00

Una ventaja de la opcion 1 .. es que los test-cases son simples .. eso
es bueno, y si modularizamos las partes que se repiten es mejor aún.

Tener test-cases muy complejos no es bueno, ya sea para entenderlos
por gente nueva, ya sea para desarrollarlos, ya sea para entender los
resultados (que fue lo que realmente pasó?? falló?, por donde fue el
flujo? porque demoró tanto?) ..

ustedes están hablando de los test que se generan a partir del modelo
no es así? de que tipo de tests generar .. si muchos simples, si uno
que obtenga los parámetros y opere de acuerdo a ellos, etc .. no?

creo que para la opción 3 .. lo mejor sería que el test-case generado
haga un buen log de lo que reprodujo (a lo mejor con gráficas y
dibujitos como nos ensenió el amigo Scott). Sino es complicado
entender que fue lo que pasó.

saludos!
Simon

No se me ocurre otra posible solución que la númer...

2009-07-07T19:59:21.901-07:00

No se me ocurre otra posible solución que la número 3.

Si realmente me choqué con el problema, muy poco la verdad, mis casos de pruebas son generalmente programados, por lo que no se compara con el uso de GXTest (porque además el UI es un tema complicado de probar, lo mio se va hacia el Backend).

Como mencionaste, con la solución 3 podrías "en runtime" saber cual de los casos deberías de ejecutar para saber si el resultado es el esperado o no.

Muchas veces el comportamiento de la aplicación es generado por la combinatoria posible de un conjunto de parámetros.

Crear un TestCase para cada una de las posibles combinatorias me parece algo excesivo (SPL podría ser una solución al acotar por línea de producto).

A los test le sumaría una buena batería de test unitarios en donde "dividiendo para conquistar" podría simular gran parte de la lógica sin tener que correr una lógica completa (se corren otros riesgos).

Pero claro, esto difiere un poco de GXTest, ya que me parece que GXTest es más hacia casos de prueba para Frontend y no tanto para Backend (si me equivoco avisen).

Encontré un ejemplo de Test Case basado en la parametrización.
"Pop-up displayed in constrained window" mencionado en el ejemplo de Chromium
http://dev.chromium.org/for-testers/frontend-testing/constrained-windows/constrained-windows--basic-testing

En el ejemplo mencionan el caso a probar, los pasos y los resultados esperados según las parametrizaciones del explorador.

Saliendo un poco ya del tema, como para ayudar un poco al usuario (por el comentario de "atado al desarrollador"), podrían ver si es posible usar es el Query Object, el cual les podría permitir crear consultas contra las diferentes parametrizaciones de una forma declarativa (sin tener que programar).

¿Podría evaluar la posibilidad de dar soporte de JSON o XML?
Con los Data Providers en la X se hace la vida mucho más simple a la hora de transformar la información.

De todas formas no se bien como actualmente propagan las parametrias contra las variables de GXTest.

Si el resultado es un tipo de dato estructurado (XML,JSON) no se como lo están procesando (se necesitaría algo como XPath/JSONPath, me imagino que si hay SOAP es posible que uno de los valores retornados sea XML)