3f blog » grails

Utilizar mockConfig en test de Grails

fernando — Tue, 24 May 2011 05:38:42 +0000

Necesitaba realizar test unitarios en una aplicación que estamos desarrollando y una de las clases que quería testear accedía, por medio del ConfigurationHolder a datos que debían ser cargados en el Config.groovy

Una búsqueda rápida en google arrojó varios resultados sobre como utilizar la magia del metaClass de groovy para mockear manualmente los objetos y métodos necesarios, pero hay mejores maneras de hacerlo.

Desde no se que versión de Grails existe el método mockConfig de la clase GrailsUnitTestCase de la cual deberían heredar todos nuestros test unitarios.

Lamentablemente no encontré mucha información sobre como usar este método por ningún lado. Solo había encontrado un blog llamado 418 I’m a teapot (en un artículo medio viejito) en el cual decían que no lo habían logrado hacer funcionar y por eso continuaban utilizando metaclass

Por suerte haciendo algunas pruebas descubrí una forma de hacerlo trabajar para mis necesidades. El secreto es que este método no acepta la sintaxis jerárquica (perdón, no se el nombre técnico) en el config, sino que debemos hacer todo más sencillamente.

Por ejemplo, en lugar de escribir

mockDomain("""
    grails {
        paypal {
            server = "https://www.sandbox.paypal.com/"
        }
    }
""")

lo que debemos escribir es

mockDomain("""
    grails.paypal.server = "https://www.sandbox.paypal.com/"
""")

De esta manera, y accediendo a la configuración por medio del ConfigurationHolder en mi aplicación, no he tenido mayores problemas.

Programar Groovy y Grails con gedit (Ubuntu)

fernando — Sun, 22 May 2011 18:13:44 +0000

Si bien he probado varios entornos de trabajo, a lo largo del tiempo, para desarrollar en Grails, siempre vuelvo a mi viejo amor: gedit (gnome-editor))

Por defecto, no tiene soporte para el lenguaje Groovy, pero es fácilmente configurable, e incluso sin necesidad de permisos de adminsitrador, permitiéndonos configurar nuestor ambiente de trabajo, sin modificar la configuración de los demás usuarios.

Para esto debemos descargar el bundle con el coloreo de sintaxis, tipos mime y otras cosas del sitio http://www.grails.org/Gedit

En esa misma página podremos encontrar instrucciones para instalarlo, que requieren de permisos de administrador. Pero combinando un post anterior en este mismo blog, sobre como hacer que gedit abra archivos tpl como si fueran archivos php y algunos otros tips más, podremos instalarlo sin necesidad de permisos especiales.

Luego de descompactar el archivo descargado, copiamos los directorios plugins, snippets y styles a la carpeta ~/.gnome2/gedit

Para arreglar el coloreo de sintaxis y enseñarle a gedit la existencia de groovy debemos crear la carpeta (si no existe) ~/.local/share/gtksourceview-2.0/language-specs y copiar en ella los dos archivos terminados en .lang que descompactamos.

Despues creamos el archivo ~/.local/share/mime/packages/Overrides.xml (y las carpetas necesarias, si no existen) y agregamos en ese archivo el contenido de los dos archivos xml que se encuentran en el bundle.

El contenido final del archivo será similar a



	
		
		Groovy Source File
		
	
	
		
		Groovy++ Source File
		
	
	
		
		Grails GSP File

Finalmente, para que el sistema reconozca nuestros cambios, debemos actualizar la base de datos de tipos mime, ejecutando el comando update-mime-database ~/.local/share/mime

Con esto, al abrir el próximo archivo de groovy, deberíamos tener coloreo de sintaxis funcionando correctamente.

Se pueden seguir haciendo otras cosas como habilitar bash completion, pero lo dejaremos para otra oportunidad.

Reflexiones y descubrimientos relacionados con mime-type, gedit y smarty

fernando — Thu, 17 Feb 2011 01:20:52 +0000

Siempre me molestó que para hacer que gedit reconozca un determinado tipo de archivos de una determinada manera, tenía que modificar archivos en el directorio /usr

Particularmente lo que me molestaba tener que actualizar eran los tipos MIME que identifican un determinado archivo, con un determinado tipo y gedit como nautilus utilizan para saber como abrir cada archivo, de que forma colorearlo, etc. Para modificar ese directorio se necesita permisos de administrador y siempre me pareció que debería haber una forma de hacerlo desde mi cuenta de usuario limitado.

Hoy, que estaba trabajado con PHP, queria abrir unos archivos de Smarty que tienen extensión tpl, y que se colorearan automáticamente como html, que es el lenguaje más cercano que reconoce (o al menos de los que vienen por defecto) y decidí buscar en internet una forma de hacerlo y encontré dos páginas, por un lado el blog de c3b en un artículo titulado Alternative method for opening Smarty templates with HTML syntax highlighting in gedit y también en la página de gnome bajo el nombre Modifying MIME types

Combinando el conocimiento de ambos sitios, logré que al hacer doble-click sobre un archivo tpl, se me abra automáticamente el gedit (y no firefox!) y se me coloree automáticamente la sintaxis como PHP

¿Cual fue el procedimiento? Fácil.

Lo primero que hice fue crear la carpeta ~/.local/share/mime/packages

En esa carpeta creé un archivo llamado Overrides.xml con el siguiente contenido

Luego ejecuté el comando update-mime-database ~/.local/share/mime

La lógica detras de este procedimiento, es que en el archivo Overrides.xml puedo crear nuevas asociaciones, o modificar exisntes. En este caso en particular, se le informa al sistema que los archivos .tpl son archivos PHP, y por lo tanto lo colorea automáticamente como PHP

Y todo esto sin usar sudo ni una sola vez

Mockear la misma clase que se esta testeando para realizar pruebas unitarias

fernando — Mon, 16 Aug 2010 05:31:40 +0000

En el artículo anterior comenté que es aconsejable aislar en diferentes métodos aquellos fragmentos de código que no pueden ser testeados unitariamente (por ejemplo las consultas con Hibernate Criterias, o Hql) de tal manera que puedan ser mockeados y de esa manera poder testear el resto del código.

Pero cuando intenté llevar a la práctica esto, descubrí que no quería crear una clase nueva para tener estos métodos, sino que quería que estén en la misma clase. Esto me planteaba un problema. Necesitaba mocker el método que no quería que se ejecutara, pero no sabía si podía mockear una clase en la cual había un método que si quería testear.

La respuesta fácil es SI, se puede, pero hay una limitación. El método que se quiere mockear hay que hacerlo utilizando metaClass. No se puede utilizar demand, como con los mocks normales, sino que se debe si o si utilizar metaClass.

Uno puede decir, que para eso no hago ningún mock, y simplemente utilizo metaClass para pisar el método en cuestión, pero lamentablemente, como dicen en muchos otros blogs, hacer eso no es seguro, y puede afectar el resultado de otros tests. (de hecho en mi se veía el error en los test de integración que comenzaron a fallar y no entendía por qué)

Basta con llamar a mockFor sobre la clase que se quiera testear, y luego se puede utilizar metaClass tranquilamente para cambiar esa clase, que cuando se termine el test los cambios se revertirán normalmente.

Se que mucho tal vez no se entienda, asi que dejaré un pequeño ejemplo comentado aquí

Quiero testear el método agregar de la clase DestacadoService. Este método internamente llama al método buscarDestacado el cual utiliza bastante hql para realizar su función, el cual no funciona en pruebas unitarias, entonces para realizar el test de agregar se necesita hacer algo similar a lo siguiente:

mockFor(DestacadoService)
DestacadoService.metaClass.buscarDestacado = { pais, tipo, id -> return null; }

def service = new DestacadoService()
def r = service.agregar(pais.argentina, tipo.principal, 'mi destacado')

Como se puede apreciar, en la línea 1 llamamos a mockFor sobre la clase que queremos mockear
En la línea 2, utilizamos metaClass para cambiar el método (y retornar algo estático que no use hql ni nada)
En la siguiente línea de código instanciamos la clase que contiene el método que queremos testar
Y finalmente, en la última lo ejecutamos

Haciendo esto nos aseguramos que luego del test el cambio sobre la clase causado por la modificación del metaClass sea revertido y no afecte al resto de los tests.

Exactamente lo mismo se debe hacer cuando se quieren modificar métodos que estén en clases de dominio. Solo que en lugar de utilizar mockFor se puede utilizar mockDomain

Como hacer pruebas unitarias con Grails que tienen método que acceden a la base de datos

fernando — Mon, 16 Aug 2010 04:44:31 +0000

Una de las tareas mas importantes, y a la vez que más esquivamos hacer son los famosos tests, tan necesarios para las metodologías ágiles que nos gusta seguir.

En grails hay principalmente dos tipos de tests. Unitarios y de Integración. Los primeros se ejecutan muy rápido pero no cuentan con todo el entorno de grails especialmente hibernate, y los segundos demoran mucho más en su ejecución, pero contamos con todas las funcionalidades de grails.

Según mi humilde opinión, debemos intentar hacer la mayor cantidad de tests posibles utilizando pruebas unitarias, ya que en mi experiencia por ser tan lentos los tests de integración, terminamos sin usarlos.

Pero nuestra intención de usar test unitarios lo más posible, se golpea contra un muro de concreto cuando intentamos testear métodos que utilizan Criterias o Hql, ya que al depender de hibernate, el cual no está disponible durante las pruebas unitarias no hay forma de hacerlos funcionar.

Un “tip” es intentar utilizar tan poco estas funciones como sea posible, y cuando no queda otro remedio que usarlas, intentar centralizar todo el código en algunos métodos que únicamente se encarguen de realizar estas consultas, los cuales serán probados con test de integración.

Si todo este código lo ponemos en una clase diferente, entonces podremos mockearla para las pruebas unitarias y el resto de nuestros métodos que no dependen de hql ni criterias, podrán ser testeados ya que se limitarán a invocar los métodos problemáticos sobre un mock, y problema resuelto.

Sin embargo a veces no queremos poner estos métodos en otra clase, sino que deseamos que sean métodos de la misma clase que estoy estoy testeando, o los métodos se encuentran en clases de dominio, y ahí se producen algunos otros problemillas que trataré en el siguiente post.

Utilizar packages en grails… una necesidad?

fernando — Wed, 10 Feb 2010 19:15:22 +0000

Todos sabemos que en Java es una muy buena práctica la utilización de packages, a tal punto que para casi todo programador de Java es casi una obligatoriedad.

El concepto de package en si es muy bueno, casi todos los lenguajes modernos lo tienen de una u otra manera, con un nombre u otro. Se utilizan para evitar coliciones de nombres entre diferentes espacios de nombres.

De tal manera, que en el package paypal puede existir la clase Payment y en el package AlertPay tener otra clase con el mismo nombre Paypal sin ninguna relación con la anterior y cohexistir en el mismo proyecto. Cuando hay una duda (ambiguedad) sobre que clase se esta utilizando basta con escribir el nombre entero de la clase, incluido el package a la que pertenece y listo.

Diciendo esto cualquiera podria ver que tienen cierta utilidad especialmente cuando se comienzan a mezclar codigos desarrolaldos en diferentes lugares (ala plugins) en un mismo proyecto y no se puede tener control sobre que dos desarrolladores no elijan nombres que entren en conflicto.

¿Pero que sucede con grails? Desde la versión 1.2.0 cuando se crea cualquier artefact (ya sea un controller, un dominio, un servicio, etc) y no se le especifica un package, aparece un warning diciendo que es aconsejable utilizar siempre un package al cual hay que contestar con yes, para poder seguir adelante.

Eso es algo bueno, pero por la forma en que funciona Grails los packages pierden un poco su sentido. No pueden haber dos clases de Dominio, ni dos clases Controllers que tengan el mismo nombre aunque esten definidas en packages diferentes! Se entiende esto dado que Grails utiliza los nombres de las cases para su “Convention Over Configuration” y de esa manera mapear facilmente los dominios a tablas con GORM, o las urls para acceder a los Controllers. (Aclaro que lo entiendo, y seguramente hay implicancias ténicas para que sea así, pero me gustaría se le encontrara alguna vuelta)

Mi caso puntual, que me motivo a escribir este post, es que estaba realizando un plugin para realizar pagos que tenía una clase de dominio llamada Payment, y debía utilizar este plugin en un proyecto que utiliza el plugin de Paypal el cual también tiene una clase de dominio llamada Payment.

Al incluir los dos plugins en un mismo proyecto y ejecutar la aplicación se genera el siguiente error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'messageSource': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Invocation of init method failed; nested exception is org.hibernate.DuplicateMappingException: duplicate import: Payment refers to both com.soluciones3f.tpv.Payment and org.grails.paypal.Payment (try using auto-import="false")

No investigaré como resolver este problema, simplemente cambiaré el nombre de mi clase para salir del paso y continuar sin problemas. Pero en todo caso es un problema latente que me gutaría encontrarle alguna solución.

Esto llevaría a pensar que, si igualmente voy a tener colision de nombres entre paquetes, ¿para que usar packages? El problema es que a veces queremos usar packages para order el código (dado que para usar packages se crean directorios.. esto lo ordena un poco y evita tener un unico directorio que mezcla Exceptions, Strategies, Utilites, etc en una sopa indistinguible) pero si alguna de estas clases que SI pertenecen a un package necesita usar una clase de dominio, que por lo que dije antes decidí no poner en un package… ahí esta nuevamente el problema.

Grails, o groovy si vamos al caso, heredan la limitación de Java de no poder hacer un import del package (default). Aquel package al que van a parar todas las clases sin package. En consecuencia no tengo forma de usarlas. Entonces, nuevamente, es muy recomendable usar siempre packages a pesar de que grails le quite un poco de sentido.

Por lo pronto, recomiendo ponerle package a todo, ya que tal vez nos puede ahorrar un dolor de cabeza si despues aparece un package que necesita usar lo que ya habia hecho antes, y si bien voy a tener que seguir coordinándome con el resto del universo para no tener dos clases con el mismo nombre, el esfuero que representa usar packages no es tan grande como para no hacerlo y desear que algún día se resuelva este problema.

Clases de dominio de Grails y sus atributos

fernando — Wed, 26 Aug 2009 19:08:11 +0000

Hace un tiempo estamos trabajando sobre un proyecto utilizando el framework Gralis para su desarrollo. Como creo que escribimos en un post anterior, este es un framework realmente comodo para Groovy que permite un desarrollo ágil, rápido y moderno que promueve una arquitectura MVC para el desarrollo de aplicaciones web.

La clase central del modelo esta representada por las clases de dominio. En estas clases uno define los atrbutos que tienen que tener, algunas reglas de constraints a cumplir antes de poder ser correctamente persistidas a la baes de datos y algunas otras relaciones con las demas clases de dominio que conforman todo mi modelo de datos.

Sin embargo hay que tener cuidado con algunos detalles a la hora de implementar estas clases.

Al usar mucho groovy, uno se acostumbra a no definir tipos de datos, y usar siempre def. Sin embargo en las clases de dominio debemos siempre definir el tipo de datos de los atributos ya que es en base a esto el como mapea y genera la base de datos subyacente.
Por defaults un atributo no puede ser Null, entonces hay que recordar de agregarlo como nullable a la definición de contraints si es que puede darse el caso. Esto lo veo perfecto, por default la forma mas restrictiva, pero suele ser justo lo contrario a lo que estoy acostumbrado.
Hay que tener cuidado con los atributos transient

Mas tarde escribiré sobre los atributos transient y los getters y setters en las clases de dominio. Pensaba hacerlo en este post, pero los problemas que traen aparejados ameritan una entrada por si misma.

Accediendo por Putty a cygwin 1.7 en Windows Vista (PuttyCyg)

fafa — Mon, 08 Jun 2009 20:57:36 +0000

Creo que el título lo dice todo. Necesitábamos usar una linea de comando “confiable” para poder trabajar cómodamente con herramientas de arquitectura para el desarrollo (el ejemplo fácil es GRAILS, también hemos trabajado con Symfony). Yo siempre conocí el PuttyCyg (una variante de Putty que permite conectarse localmente a una instalación de CygWin).

Por si no saben, cygwin es una especie de emulación de librerías de *nix realizada por Red Hat; por ello, establece una infraestructura para ejecutar comandos que normalmente estarían en *nix. Putty es un cliente de consola que normalmente uno usa para conectarse remotamente a un máquina ejecutando un sistema operativo *nix (el típico ejemplo es un servidor SSH).

Entonces, lo interesante es que buscando un poco en internet encontramos la forma de usar una linea de comando, muy similar a la de *nix en un entorno Windows… Si! La forma de lograrlo es la siguiente:

Incluir en el PATH el directorio donde esté el cygwin1.dll (ejemplo: c:\cygwin\bin).
Setear la variable de entorno NOCYGWIN=1 que le dice al PuttyCyg que no busque la configuración en la registry.
Ejecutar el Putty: putty.exe -cygterm -
En el mejor de los casos, hacer un acceso directo con lo resaltado en el punto anterior.

Listo! Ahora deberíamos ser capaces de usar cualquier cosa desde windows como si fuera *nix.

Una sugerencia adicional, cuando se quieren hacer “cd” recuerden que la forma en que se muestran los directorios en *nix no tiene unidades, sin embargo, al usar comillas automáticamente cygwin lleva ese comando al cmd “verdadero”. Por ello, cd “D:\grails” nos hará un internamente cd /cygdrive/d/grails.

Como para tenerlo en cuenta, espero que les sirva. Me basé en lo que encontré en: http://code.google.com/p/puttycyg/issues/detail?id=16

Actualización a Grails 1.1.1 cuando uno tiene configurado IVY

fafa — Wed, 20 May 2009 19:56:54 +0000

Hace poco más de un mes, estamos trabajando fuertemente en el desarrollo de una (en realidad más de una) aplicación web construida con la herramienta de orquestación GRAILS. Es interesante como está construida porque, para los fanáticos de MAVEN (por ejemplo) da un paso más adelante y prepara una serie de cualidades en el entorno que simplifica mucho a la hora de desarrollar. Para quienes no entienden del tema, tendrán más detalles en un POST proximamente.

Una de estas aplicaciones que estamos desarrollando con Grails tiene configurado el plugin de IVY; IVY es un manejador de dependencias que está dentro del paquete de herramientas de Apache; cuando intentamos hacer el upgrade (desde la versión 1.1 a 1.1.1) nos encontramos con una serie de errores:

Error executing script Upgrade: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
gant.TargetExecutionException: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:331)
        at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
        at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
        at gant.Gant.withBuildListeners(Gant.groovy:344)
        at gant.Gant.this$2$withBuildListeners(Gant.groovy)
        at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
        at gant.Gant.dispatch(Gant.groovy:334)
        at gant.Gant.this$2$dispatch(Gant.groovy)
        at gant.Gant.invokeMethod(Gant.groovy)
        at gant.Gant.processTargets(Gant.groovy:495)
        at gant.Gant.processTargets(Gant.groovy:480)
Caused by: : java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at Upgrade$_run_closure1.doCall(Upgrade:82)
        at Upgrade$_run_closure2.doCall(Upgrade:261)
        at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
        ... 10 more
Caused by: java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.createTempFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/File;ZZ)Ljava/io/File;
        at org.apache.tools.ant.taskdefs.optional.ReplaceRegExp.doReplace(ReplaceRegExp.java:326)
        at org.apache.tools.ant.taskdefs.optional.ReplaceRegExp.execute(ReplaceRegExp.java:527)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
        ... 17 more

Básicamente el problema es que el script que ejecuta GRAILS pone en classpath en primera instancia nuestro directorio lib, en condiciones normales esto sería lógico (porque nuestra aplicación puede usar una versión más nueva de algo que GRAILS no usa) pero en estas condiciones resulta en un error del script conocido como Upgrade.groovy es por eso que terminamos ese error.

¿Cuál es la solución? Fácil, movemos a un directorio temporario todo nuestro directorio lib, ejecutamos upgrade y volvemos a mover todo al lugar donde estaba Tendremos la aplicación actualizada sin mayores problemas, jijiji.

La idea, no fue mía, fue obra y gracia de Google . Aquí el link original.