tag:blogger.com,1999:blog-3360428795422884065.post3597284178812084702..comments2009-08-10T10:23:01.712-07:00Fabián Baptistahttps://profiles.google.com/111746128060367103556noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-3360428795422884065.post-5122813440069626342009-08-10T10:23:01.712-07:002009-08-10T10:23:01.712-07:00Excelente!! yo lo compro !!!<br /><br />Es una excelente idea!!!<br />Me parece genial, ya me veo programando con esa metodología en GeneXus.<br /><br />¿¡¿Ya me puedo anotar al betatesting de GXTest 2.0!?!?! <br /><br />quedo a la espera del próximo post!!<br /><br />Salu2 y éxitos!!David Giordanohttp://www.blogger.com/profile/07375617932691372782noreply@blogger.comtag:blogger.com,1999:blog-3360428795422884065.post-3012248104691216132009-08-10T09:58:41.520-07:002009-08-10T09:58:41.520-07:00David,<br /><br />Para mi que hay que separar un poco lo que es ejecuciones a nivel de desarrollador y a nivel de GXtest Server, en donde testeas sobre ambiente consolidado, o de testing. Estamos preparando otro post para dejar esto más en claro de cómo lo vemos. <br />Cada uno luego lo va a adaptar a su metodología, pero yo veo más asociado el tema de ejecutar algunos TC en forma guiada según los cambios a nivel de desarrollador, y a nivel del Consolidado en el GXtest Server ejecutar según un plan. Esto puede cambiar tal vez a futuro de acuerdo a las necesidades :)<br /><br />Por eso está buena la idea de integrarse al IDE de Genexus a futuro a modo de darle la posibilidad al desarrollador de tener sus propias pruebas a ejecutar antes de enviar su código a la integración.<br /><br />Cómo lo ves?FedeFedehttp://www.blogger.com/profile/00850305053856498167noreply@blogger.comtag:blogger.com,1999:blog-3360428795422884065.post-89454460050796037172009-08-10T09:29:45.996-07:002009-08-10T09:29:45.996-07:00Lo que Visual Studio 2010 propone no es tan nuevo, y en si se basa en detectar el origen del cambio, y subir en el árbol de dependencias hasta encontrar alguno de los elementos del árbol dentro de un TestCase (ya en otras comunidades este tipo de tendencia se estaba dando, con extensiones desarrolladas sobre el IDE).<br /><br />Hoy en día la tendencia es incorporar al IDE de la posibilidad de hacer Test de las cosas tocadas por pruebas unitarias &quot;en caliente&quot;, a efectos de detectar los problemas de la forma más pronta posible.<br /><br />¿Lo están proponiendo en el IDE de GeneXus? o que corra contra el GXTest Server ?<br /><br />Yo me lo imagino de esta forma:<br /><br />Si se cuelgan de cambios en los programas, podrían llegar a detectar los TestCase, y si tienen la lista de dependencias hasta la pantalla llegarían, me imagino luego un listado de cambios del día. Ese listado luego se publicaría en GXTest Server para que tome la decisión de que TestCases correr.<br /><br />Ahora bien, para la pregunta final, me imagino que GXTest Server debería de tener información de dependencia de parametrizaciones por TestCase, como para poder detectar cambios en las mismas para correr los Testcase.<br /><br />La otra es que sea por delegación, si un TestCase se encuentra condicionado por la lógica de un programa que retorna si debe ejecutarse o no, se podría programar esa lógica para cada TestCase y en la noche con la corrida de cada TestCase en GXTest Server se tomaría la decisión si se corre o no (Mezclado el concepto con el caso de los cambios en lógica obtenido del IDE).<br /><br />Algo que estaría bueno es que a medida que se realizan cambios y se detecten modificaciones sobre programas que afecten Testcases, los mismos se ejecuten para dar al desarrollador un impacto inmediato (con GXTest Server o con el cliente).<br /><br />Estaría bueno algo así, para ir hacia lo que se denomina &quot;Continuous Testing&quot; http://blog.objectmentor.com/articles/2007/09/20/continuous-testing-explained<br /><br />Seguramente también esto genere que se tengan que definir y declarar diferentes tipos de TestCase a ser corridos unos de forma continua (por ser test tendiendo a unitarios), y otros a ser corridos de forma nocturna, por ser test de cobertura de una funcionalidad completa.<br /><br />Me quedo con &quot;la pica&quot; de la pregunta final... ¿que tienen planeado para GXTest a futuro ? o GXTest ya tiene algo similar para su versión liberada ?David Giordanohttp://www.blogger.com/profile/07375617932691372782noreply@blogger.comtag:blogger.com,1999:blog-3360428795422884065.post-55952404359496799172009-08-10T08:13:38.713-07:002009-08-10T08:13:38.713-07:00El tema de la relación Caso de prueba Objetos Genexus es bastante complejo.<br /><br />Si se hace de manera manual, es muy tedioso y si se hace de manera automática es difícil de que quede completo. <br />De manera automática se puede considerar los impactos que mencionas Enrique, pero luego el link con los casos de prueba es complejo.<br /><br />Un aproach es el que propone MS, eso sin duda te da una lista inicial de Objetos relacionados. Ahora al cambiar lógica y datos esos objetos relacionados pueden cambiar, por lo que es importante que esa lista se vaya actualizando en cada corrida del caso de prueba.<br /><br />Me parece que es interesante seguir profundizando en esto, sobre todo para cuando se quieren correr pruebas en el ambiente de desarrollo.MelliMatíashttp://www.blogger.com/profile/05589011792765234083noreply@blogger.comtag:blogger.com,1999:blog-3360428795422884065.post-18224772857340401912009-08-10T07:45:14.285-07:002009-08-10T07:45:14.285-07:00En el caso de GeneXus, elegir que pruebas ejecutar, esta asociado a un &quot;analisis de impacto ampliado&quot;. <br /><br />Al realizar cualquier cambio deberia poderse evaluar cuales son los objetos se tuvieron que regenerar (porque usan objetos de la base de datos que cambiaron o porque el objeto cambio). <br /><br />Los casos de prueba a ejecutar, son todos los que usan cualquier objeto que cambio (objetos que se regeneran). <br /><br />Si tenemos la relacion Caso de Prueba - Objeto GeneXus definida, no deberia ser dificil elegir todos los objetos que se necesitan correr.<br /><br />Supongo que los TestCases pueden verse afectados por algunas otras cosas como cambios en los datos de prueba, propiedades del modelo de pruebas, o dependencias entre los TestCase que obliguen a ejecutar mas pruebas.Enrique Almeidahttp://www.blogger.com/profile/13964187630117314432noreply@blogger.com