Bref, nous ne sommes pas ici pour parler de GWT tout seul mais plutôt de la façon dont on écrit des tests pour cette technologie. Armé de notre JUnit favoris et de Mocks en tout genre (pour Spring, pour les Web Services, tout ça…) nous sommes pourtant démunis face à GWT. En effet dès l’écriture du premier test unitaire (qui ne ferait que créer un objet par exemple) nous avons une erreur de ce type :
java.lang.ExceptionInInitializerError
[...]
Caused by: java.lang.UnsupportedOperationException: ERROR: GWT.create() is only usable in client code! It cannot be called, for example, from server code. If you are running a unit test, check that your test case extends GWTTestCase and that GWT.create() is not called from within an initializer or constructor.
at com.google.gwt.core.client.GWT.create(GWT.java:91)
at com.google.gwt.user.client.ui.UIObject.(UIObject.java:139)
... 23 more


Ok, pas très grave puisqu’apparement Google y a pensé et nous donne même la solution : on étends la classe GWTTestCase, on refait la même chose et ça devrait marcher. Et c’est vrai ça marche, alors où est le problème ? Le problème c’est que GWT a besoin de lancer son navigateur pour exécuter les tests et que c’est gourmand en ressources et en temps d’exécution (ceux qui font des tests avec un contexte Spring complet savent de quoi je parle).

Hors je travaille sur des projets en méthodologie Agile (avec du TDD dedans), et la fréquence de passage des tests unitaires est très élevée. Contrairement aux tests d’intégration qui sont exécutés moins souvent, le passage des tests unitaires fait partie du processus de création du code, il est donc impensable d’attendre 10 à 15 secondes que le test veuille bien se lancer alors qu’on peut en avoir besoin plusieurs fois par minute !

Actuellement nous avons plus de 1200 tests unitaires sur le projet, et ils s’exécutent sur ma machine en environ 26 secondes et le lancement d’un test lambda est instantané (aussi rapide qu’un test junit classique en tout cas). Nous avons donc contourné le problème en étendant notre propre classe de test GWT mais en choisissant une autre stratégie que Google.
Notre solution a été de patcher les classes GWT au runtime à l’aide d’une librairie spécifique et d’un JDK 1.6. Je passe sur le code lui même car il est utilisé en clientèle mais le principe consiste à intercepter les appels de méthodes GWT qui produisent du code natif JavaScript (JSNI de Google) afin de produire un comportement équivalent en Java.
L’effort consenti en début de projet a été relativement important (création du code pour couvrir 100% des besoins spécifiques du projet, corrections de bugs…) mais le gain est considérable puisque nous avons pu appliquer nos méthodes de développement sans être contraint par cette technologie à avoir une productivité inférieure.
Le projet sur lequel cette solution est mis en place fait travailler une petite dizaine de développeurs depuis plus de 6 mois chez un grand compte, ce n’est pas la refonte d’un SI, mais ce n’est pas non plus du bricolage dans un garage.

Ma question est : comment vous vous faites pour écrire des tests avec GWT ? Pour quelle taille de projet ? Est ce que la solution fournit par Google vous suffit ?

L’installation du plugin Maven pour Netbeans se fait simplement via l’interface d’ajouts de plugins, sans ajouter de dépot particulier. Une fois installé, on a l’impression que l’IDE n’a jamais été conçu autrement que pour travailler sur des projets Maven. Je passe sur l’import (simplissime) d’un projet Maven qui n’est pas l’objet de cet article…

Une fois un projet ouvert (avec des modules tant qu’à faire) toute l’interface et les menus s’adaptent au projet Maven. En dépliant le projet parent, on découvre une liste de modules, les librairies rangées par scope, et les répertoires habituels de sources, de tests et le reste…

Le menu contextuel d’un projet permet de lancer les commandes Maven les plus courantes (build, clean and build, test), de modifier les profils (récupérés dynamiquement depuis le pom), etc…

NetBeans utilise exclusivement le pom.xml et ne pollue pas le workspace comme Eclipse de multiples fichiers (.project, .classpath, .settings, etc… à ajouter au svn ignore). Le seul fichier spécifique est créé lors de l’ajouts de commandes définies par l’utilisateur sur les Goals Maven à exécuter pour un projet.
Le lancement ponctuel de fichiers de tests est aisé. Un simple clic droit sur le fichier JUnit, puis « Run file » et le tour est joué : le build Maven se déroule pour lancer l’unique fichier de test. La modification du nom de l’artefact renomme le projet en temps réel, il n’y a pas de décalage entre les erreurs remontées par l’IDE et ceux du build Maven… Bref tout marche pour le mieux même si je n’ai sans doute pas poussé l’outil jusqu’au bout. Pour ceux qui aimeraient approfondir le sujet il y a un wiki sur le site de NetBeans qui couvre le sujet.

Un bémol tout de même, si NetBeans sais gérer plusieurs répertoires sources pour un projet Java classique, il semble qu’il ai quelques difficultées à gérer le plugin Maven qui remplit ce rôle. Nous avons en effet le code suivant dans un fichier pom.xml sur un projet :
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>
${basedir}/src/main/axisgenerated
</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>

Mais le problème c’est que NetBeans n’identifie pas ce répertoire comme source et est incapable de résoudre les imports sur ces fichiers… En revanche si l’IDE signale des erreurs, le build Maven lui fonctionne correctement (sans surprise). Peut être que quelqu’un connaît une autre façon de faire qui fonctionne pour répondre à ce besoin ?

Comme HSQL, les points forts de cette BDD sont une faible empreinte mémoire et un mode embarqué très performant. Les graphiques du site officiel sont d’ailleurs assez révélateurs sur les performances que l’on est en droit d’attendre de ce produit…

Un problème tout de même… Alors qu’une grande quantité d’applications JEE utilise Hibernate pour la persistance, le dialecte relatif à H2 est bugué. Cette petite classe est responsable de la traduction du code Hibernate en requêtes SQL. Un problème qui n’est toujours pas adressé malgré la sortie de la version 3.3 du framework alors qu’un patch est disponible depuis un certain temps déjà…

J’aimerais beaucoup l’utiliser pour le projet sur lequel je travaille en ce moment, mais je préfère attendre la prise en compte du patch… Est ce que quelqu’un a des retours sur l’utilisation de cette base de données dans la vrai vie ?

The first step is to create a GSP which defines the template. It should be noted that no special tag will be interpreted this way. Here is a sample VCARD file to import a contact (_vcard.gsp) :
BEGIN:VCARD
VERSION:2.1
N:${people.lastname};${people.firstname};;${people.civility}
FN:${people.civility} ${people.firstname} ${people.lastname}
TITLE:${people.job}
TEL;WORK;VOICE:${people.professionnalPhone}
EMAIL;INTERNET:${people.email}
END:VCARD

Then we must add a small method that will link the template to the data through the Groovy’s template engine :

class MyUtilityClass {
static SimpleTemplateEngine engine = new SimpleTemplateEngine()
static generateFromGSP(String templateFilename, model) throws Exception {
Template template = engine.createTemplate(new File(templateFilename))
return template.make(model).toString()
}
}

And finally all that remains is a call from a piece of Groovy code, in a controller for example :
def myVcard
People myContact = People.findByName('lorenzo')
myVcard = MyUtilityClass.generateFromGSP("_vcard.gsp",['people':myContact])

That’s all.. The myVcard variable contains the template supplied with data from myContact, we can now send it to a web browser to download it for example ..

This is not necessarily highlighted in the documentation, but the use of GSP from the inside of the Grails application grails to create templates is even easier.
Just do the same way as from the inside of a classical GSP, as the methods of the taglib are available. Here is the same result as the example above, but with a GSP located in the project :
People myContact = People.findByName('lorenzo')
vcard = g.render(template: "/myTemplates/vcard", model: ['people':myContact])

The solution is to modify the following spring’s confguration file : WEB-INF/classes/spring-beans.xml replacing :
<bean id="metaRepository" class="com.technoetic.xplanner.domain.repository.MetaRepositoryImpl">
<property name="repositories">
<map>
[...]
</map>
by
<bean id="metaRepository" class="com.technoetic.xplanner.domain.repository.MetaRepositoryImpl">
<property name="repositories">
<bean class="java.util.HashMap">
<constructor-arg>
<map>
[...]
</map>
</constructor-arg>
</bean>
[...]

The bug is notified on the Jira bugtracker of the project since some time, but is still to be fixed…

Ça a commencé très fort avec le discours de Michel Serres sur l’innovation ; ou comment l’informatique, après l’écriture et l’imprimerie, marque une 3ème révolution dans l’histoire de l’humanité. Malgré l’heure matinale, le philosophe a su captiver l’attention de son auditoire et provoquer l’enthousiasme des quelques 300 personnes présentes dans la salle !
Et de finir sur « Tout est là devant vous, sous vos mains. Il ne vous reste plus qu’à inventer ! », il n’en fallait pas plus pour marquer le coup d’envoi d’une journée qui s’annonçait riche d’enseignements.

Puis ce fut la course aux sessions. Ayant opté pour le parcours libre, j’ai du effectuer des choix souvent difficiles pour sélectionner le contenu de mes journées face à l’importante densité du programme.

En quelques mots la première journée fut orientée sur l’ergonomie, les mythes de l’informatique, l’usine de développement, les tests, l’innovation et la productivité. La seconde m’a permis d’approfondir les thèmes de l’Agilité, la SOA, TDD et les DSL.
C’est donc avec regrets que j’ai du me passer des sessions sur le Lean, Google, la virtualisation, etc…

Premier constat, toutes les sessions auxquelles j’ai pu assister étaient de grande qualité. Ayant suivi la préparation de l’intérieur ce ne fut pas une grosse surprise, mais tout de même le résultat final est impressionnant. Je ne suis d’ailleurs pas le seul à le ressentir d’après les premiers echos que j’ai pu en avoir…

Si j’étais déjà convaincu de l’intérêt de l’approche Agile et TDD, j’ai pu bénéficier de quelques éclairages bien pratiques sur leur mise en oeuvre concrète, les pièges à éviter et de nouvelles idées à expérimenter. Dans l’ensemble et y compris sur les autres sujets, j’ai pu apprécier le concret que j’ai pu retirer des sessions et dont je pourrais faire l’usage dès mon retour en projet.

Les pauses entre les sessions étaient l’occasion de rencontrer quelques clients et d’échanger sur leurs problèmes mais aussi de bénéficier de points de vus différents, car deux populations étaient adressées à l’USI ( »geek » et « boss »). Plus concrètement des sessions de « Speed Consulting » ont été mises en place afin que les speaker puissent êtres directements sollicités par les participants.

Et les keynotes… du beau monde ! Je ne vais pas revenir sur Michel Serres, mais nous avions également le plaisir d’accueillir :

• Bjarne Stroustrup l’inventeur du C++, toujours passionné après plus de 20 ans… un peu aigri apparement face à Java mais finalement ça semble de bonne guerre. Qu’aurais donné C++ s’il était apparu à l’ère du Web et de l’Open Source ? En effet un de ses grands regrets est l’absence d’une communauté claire et unie autour de ce langage… qui a la peau dure !
• Eliyahu M. Goldratt, l’auteur du best seller « Le But », dont le discours ne peux pas m’empêcher de repenser à une célèbre phrase qui dit que « l’informatique est partout, sauf dans les statistiques de productivité » !
• Et enfin… Neil Armstrong ! Son arrivée sur la scène pour clore le séminaire restera le point d’orgue de ces deux jours. Nous aurions pu rester longtemps à l’écouter, mais voilà il n’était là qu’une petite heure. Une petite heure néanmoins unique, pleine d’émotions, de rêve et d’humanité.

Un grand merci à tous mes collègues qui se sont donnés à fond pour organiser cet évènement, ça en vallait la peine !

Est ce que j’y retourne l’année prochaine ? Sans hésitation ! Peut-être bien que je ferais une présentation cette fois là !

La solution est de modifier le fichier de configuration de spring WEB-INF/classes/spring-beans.xml en remplaçant :
<bean id="metaRepository" class="com.technoetic.xplanner.domain.repository.MetaRepositoryImpl">
<property name="repositories">
<map>
[...]
</map>
par
<bean id="metaRepository" class="com.technoetic.xplanner.domain.repository.MetaRepositoryImpl">
<property name="repositories">
<bean class="java.util.HashMap">
<constructor-arg>
<map>
[...]
</map>
</constructor-arg>
</bean>
[...]

Le problème est remonté sur le Jira du projet depuis un certain temps, mais n’est toujours pas fixé…

Prenons un exemple d’utilisation en Java…

private static ThreadLocal<String> remoteUser = new ThreadLocal<String>() {
    protected synchronized String initialValue() {
        "inconnu";
    };
};

private static setRemoteUser(String p_user) {
    remoteUser.set(p_user);
}

public static String getRemoteUser() {
    return remoteUser.get();
}

Vous pouvez reprendre cette portion de code et l’intégrer dans une classe Groovy (avec les bons imports) vous constaterez immédiatement que le compilateur n’apprécie pas vraiment cette façon de faire… Voici maintenant l’équivalent en Groovy de cette portion de code :

private static ThreadLocal<String> remoteUser = [
    initialValue: { return UNKNOWN_USER }
] as ThreadLocal<String>;

private static void setRemoteUser(String user) {
    remoteUser.set(user)
}

public static String getRemoteUser() {
    remoteUser.get()
}


La différence de syntaxe est assez flagrante, mais il y également un point très important auquel il faut faire attention, c’est le point virgule sur cette ligne : as ThreadLocal<String>;. Si celui ci est supprimé, le parseur semble avoir quelques difficultées et ne distinguera pas la fin de l’instruction. Contrairement aux habitudes il faudra donc conserver cet élément dans ce cas bien précis.

La première étape consiste à créer une GSP qui définit le template. Il faut noter qu’aucun tag spécial ne sera interprété de cette manière. Voici un exemple de fichier VCARD pour importer un contact (_vcard.gsp) :
BEGIN:VCARD
VERSION:2.1
N:${personne.nom};${personne.prenom};;${personne.civilite}
FN:${personne.civilite} ${personne.prenom} ${personne.nom}
TITLE:${personne.poste}
TEL;WORK;VOICE:${personne.telephonePro}
EMAIL;INTERNET:${personne.email}
END:VCARD

Ensuite il faut ajouter une petite méthode qui se chargera d’associer le template aux données grâce au moteur de template de Groovy :

class MaClasseUtilitaire {
static SimpleTemplateEngine engine = new SimpleTemplateEngine()
static generateFromGSP(String templateFilename, model) throws Exception {
Template template = engine.createTemplate(new File(templateFilename))
return template.make(model).toString()
}
}

Et enfin il ne reste plus qu’à effectuer l’appel depuis un bout de code Groovy, dans un controller par exemple :
def maVcard
Personne monContact = Personne.findByName('lorenzo')
maVcard = MaClasseUtilitaire.generateFromGSP("_vcard.gsp",['personne':monContact])

C’est tout.. la variable maVcard contient le template alimenté avec les données de monContact, il ne reste plus qu’à l’envoyer au navigateur pour la télécharger par exemple..

Ce n’est pas forcément mis en évidence dans la documentation mais l’utilisation de GSP internes à l’application grails pour les templates est encore plus simple. Il suffit de procéder de la même façon que depuis une GSP classique, les méthodes de la taglib étant disponibles. Voici le même résultat que l’exemple ci dessus, mais avec une GSP située dans le projet :
Personne monContact = Personne.findByName('lorenzo')
vcard = g.render(template: "/mesTemplates/vcard", model: ['personne':monContact])

Au programme, plus de 30 sessions animées par des experts d’Octo et de l’extérieur sur des sujets variés et répondant à des thématiques de technologie, de gouvernance, de méthodologie et d’architecture.

Agrandir le plan