El comando para ejecutar las pruebas en Grails es el siguiente:
Con este comando ejecutamos todas las pruebas que tengamos definidas, las unitarias y las de integración. Cuando estás codificando las pruebas unitarias y quieres lanzarlas poco a poco resulta molesto tener que esperar a que arranque todo el framework y que se ejecuten también las pruebas de integración.
Si quieres ejecutar sólo las pruebas unitarias ejecuta el siguiente comando:
Para ejecutar sólo las pruebas de integración:
>$ grails test-app -integration
Y en cualquier caso, si quieres filtrar para ejecutar sólo las pruebas que has definido en un fichero, añade el nombre de dicho fichero al final de la línea de comandos (sin el sufijo “Tests“):
1
2
3
| >$ grails test-app -integration MisPruebas
>$ grails test-app -unit MisPruebas
>$ grails test-app MisPruebas |
El comando de la línea 1 ejecutaría las pruebas de integración definidas en el fichero MisPruebasTests.groovy. El comando de la línea 2 ejecutaría las pruebas unitarias definidas en el fichero MisPruebasTests.groovy, y el tercer comando ejecutaría todas las pruebas que hallara en un fichero con nombre MisPruebasTests.groovy. Recuerda que grails distingue entre las pruebas unitarias y las de integración en función de la carpeta en la que estén colocados los ficheros de prueba: test/unit para las primeras y test/integration para las segundas.
Llegó el momento de las pruebas, no se pueden posponer más. En Grails existía un plugin que facilitaba mucho esto de las pruebas unitarias y de integración. Facilitaba tanto la labor que a partir de la versión 1.1 decicieron integrarlo en la rama principal de Grails. Y yo que me alegro porque merece la pena.
Son muchas las cosas que podemos probar y Grails nos ayuda en muchos temas específicos proporcionándonos clases de las que extender para desarrollar nuestros tests. Tendremos que dejar nuestras pruebas en los directorios test/integration o test/unit, siguiendo la jerarquía de paquetes de los elementos a probar y heredando de determinadas clases en función de lo que estemos probando:
Para lanzar las pruebas deberemos ejecutar la siguiente orden desde la línea de comandos:
En futuros posts iré hablando del resto de pruebas, pero ahora me centraré en las relacionadas con los mapeos de URL’s.
Read more…
Esto no va a ser una comparativa exhaustiva entre Groovy, Prolog y Python, simplemente unos snippets que intercambiamos mi colega fortran y yo hace un tiempo.
Contextualizemos: yo no sé Python, él no sabe Groovy, y probablemente el conocimiento que tiene él sobre Python es mayor que el que tengo yo sobre Groovy. Lo de Prolog tiene que ver con la universidad, el ansia por terminar prácticas y espinitas clavadas :-). Lo cierto es que hoy por hoy él controla mucho más que yo en programación lógica.
Quizás a alguien le resulte interesante, y en cualquier caso servirá en el futuro para recordar lo que éramos capaces de hacer (en ocasiones las mierdas del pasaso parecen ahora inalcanzables, no me lo negarás).
Read more…
Este post es una continuación de Grails + JMS + Email, donde se explicaba cómo configurar Grails 1.0.4 para que se enviaran emails mediante JMS. Una vez actualizado a Grails 1.2-M2 algunas de las cosas que comenté en su momento dejan de ser válidas.
Además se repasan los pasos básicos para definir un clúster en glassfish y se dan algunos consejos sobre aspectos a tener en cuenta y que pueden provocar errores dificilmente detectables.
Read more…
La situación es la siguiente: un usuario origina la ejecución de una acción en el servidor, la cual debe realizar una o varias tareas que pueden requerir una gran cantidad de tiempo y cuyo estado final no influye en la respuesta que se envíe al usuario. Nuestro caso concreto: envío de emails como consecuencia de una acción solicitada por un usuario.
En Thuest esta situación se repite bastantes veces. Por ejemplo, cuando un usuario se hace fan de otro se le envía un correo a este último informando. Un primer desarrollo de la acción convertirseEnFan podría ser:
1º Recuperar de la BBDD el nuevo ídolo
2º Crear y guardar una nueva instancia Fan, que relacione al usuario de sesión y al ídolo recuperado
3º Mandar un email al ídolo
4º Renderizar la respuesta al usuario
El paso que nos interesa es el tercero. Si ese envío se realiza de forma síncrona la acción completa sufrirá una penalización bastante grande respecto al tiempo necesario. La comunicación con el servidor SMTP puede retrasarse y si a esto le sumamos que podemos tener acciones que conlleven el envío de muchos emails, realizar esta operación de forma asíncrona resulta muy interesante.
Podríamos tirar por el camio de en medio y crearnos threads para que hicieran el trabajo, incluso podríamos usar un pool de threads si queremos ser más elegantes. Pero en Java tenemos JMS, que a mi es lo primero que se me viene a la cabeza en estos casos. Además, una vez configurado JMS verás como se te ocurren muchas aplicaciones (el tema los topics da mucho juego y puedes montar un sistema de notificaciones bastante chulo).
Read more…