Par Anthony Lopes Barata.

L’objectif de ce tutoriel est de remplacer les tableaux générés par Spring ROO par des composants dynamiques dhtmlxGrid et ainsi permettre d’y ajouter des fonctionnalités en utilisant l’API dhtmlx ou des fonctions Javascript diverses. Nous nous appuierons sur le tutoriel de création d’une application Spring Roo (Pizza Shop) avec Jetty intégré (facultatif).

Le composant dhtmlxGrid intégré à l'application Spring ROO Pizza Shop

- Il faut tout d’abord ajouter les fichiers nécessaires au chargement de la dhtmlxGrid dans le répertoire src/main/webapp de l’application (disponibles sur http://dhtmlx.com/docs/products/dhtmlxGrid/index.shtml ).

- Puis créer un fichier alternatif de génération de tableau: dupliquer src/main/webapp/WEB-INF/tags/form/fields/table.tagx et renommer la copie en table_dhtmlxGrid.tagx, dans le même répertoire.

- Dans ce fichier alternatif, supprimer le contenu entre les balises html <table> et </table> (incluses) qui sert à créer une table html classique (que l’on cherche donc à remplacer), et remplacer par le script de la dhtmlxGrid.

Ici:

<link rel=”STYLESHEET” type=”text/css” href=”/Pizza/dhtmlxGrid/codebase/dhtmlxgrid.css”></link>
<link rel=”stylesheet” type=”text/css” href=”/Pizza/dhtmlxGrid/codebase/skins/dhtmlxgrid_dhx_skyblue.css”></link>

<script type=”text/javascript” src=”/Pizza/dhtmlxGrid/codebase/dhtmlxcommon.js”>
<!–Placez ici le code de votre script// –>
</script>
<script type=”text/javascript” src=”/Pizza/dhtmlxGrid/codebase/dhtmlxgrid.js”>
<!–Placez ici le code de votre script// –>
</script>
<script type=”text/javascript” src=”/Pizza/dhtmlxGrid/codebase/dhtmlxgridcell.js”>
<!–Placez …

Dans ce billet, je vais mettre en œuvre un serveur Jetty Embedded sur une application Spring, afin d’obtenir les fondations d’un système de tests automatisés et semi-automatisés.

En effet, l’objectif, en ce qui me concerne, est de faciliter la recette d’applications via les deux méthodes suivantes :

Spring apporte, entre autres, deux avantages appréciables :

Je vais m’appuyer sur le tutoriel Beginning With Roo, qui consiste à créer une application de gestion pour une pizzeria, nommée Pizza Shop. L’application permet de confectionner des pizzas et de gérer des commandes.

L’objectif est de mettre en place les fondations pour les deux types de tests décrits ci-dessus. En l’occurrence la partie initialisation des données …

Afin de donner un début de réponse à la question posée dans mon dernier billet “Peut-on vraiment industrialiser l’installation d’Eclipse avec p2 ?“, voici un tour d’horizon des capacités et des manques de cette plateforme de provisioning, à travers l’utilisation du p2 agent.

L’interface graphique de cet agent donne un aperçu des capacités de p2. Nous verrons comment installer “from scratch” un SDK minimal ou une distribution Eclipse complète. Nous mettrons aussi en application le “bundle pooling” qui permet d’utiliser un référentiel de plugins, partagé par plusieurs instances d’Eclipse.

Commençons par télécharger l’agent. Sur la page des téléchargements Equinox, choisir par exemple la release 3.5.2. Le lien de téléchargement de l’agent p2 se trouve dans la section “Provisioning” de la page de téléchargement de cette release.

Téléchargement du p2-agent

L’agent p2 est bien sûr une application Eclipse, donc son installation se fait de façon classique, en décompressant l’archive. On retrouve aussi l’habituel eclipse.exe, pour la version Windows.

L'interface du p2-agent

La partie supérieure de l’interface présente les dépôts disponibles dans deux onglets. p2 distingue les Metadatas des Artifacts car il est capable de gérer les uns indépendamment des autres. Cela dit, en pratique, les dépôts sont …

Comme l’indique Benjamin Cabé dans son article “Déployer avec Equinox p2” (version anglaise ici sur Eclipse Zone), P2 était trop jeune en février 2009 pour être utilisé dans une logique d’industrialisation des déploiements. Mais qu’en est-il maintenant, un an plus tard ?

Cette plateforme de provisioning apporte de réelles solutions aux problématiques d’installation de produits OSGI, à commencer par les applications Eclipse RCP.

Mais ce qui m’intéresse particulièrement, c’est une autre des promesses de P2 : l’installation industrialisée des environnements de développement Eclipse eux-mêmes. L’intérêt est multiple : gain de temps, outils et configurations identiques pour tous les membres d’une équipe projet, gestion centralisée des mises à jour, pérennité des “dispositifs qualité” mis en place (voir mon précédent article à ce sujet : L’importance d’automatiser l’installation et la configuration des environnements de développement pour réduire la dette technique), etc.

Dans ce contexte de provisioning industriel, les apports de P2 sont indéniables :

• Capacité d’installer Eclipse “from scratch”, contrairement à l’Update Manager, son prédécesseur, qui permettait uniquement de personnaliser Eclipse après son installation.
• Possibilité de définir des profils d’installation …

Un ch’ti Mockito ?

C’est avec grand plaisir que nous vous convions à la prochaine session du CH’TI JUG, qui se déroulera le mardi 20 avril prochain, à 18h30 à la Maison des Associations de Lille.

David Gageot, directeur technique d’Algodeal, nous présentera deux sujet lors de cette session : GIT et Mockito.

De nouveaux paradigmes de développement collaboratif émergent ces temps-ci et GIT constitue l’une des avancées techniques les plus remarquables dans ce domaine.

Mockito, quant à lui, parvient à s’imposer, dans un écosystème pourtant déjà richement fourni en frameworks de mocking, par la simplicité qu’il confère en matière de développement de tests unitaires.

Tous les détails concernant cette soirée sont sur chtijug.org.

Obeo a profité du premier PMC Obeo Network, jeudi soir, pour annoncer à ses partenaires l’arrivée prochaine d’Acceleo 3, prévue fin Juin.

Il reste néanmoins du travail pour finaliser cette version dont les fonctions de “traçabilité” ne sont pas encore opérationnelles. La traçabilité tient un rôle essentiel dans le développement de générateurs en offrant la capacité de “remonter” du code généré au template de génération ou au modèle d’entrée.

Acceleo 3 introduit un nouveau format pour les “templates” de génération.
Se pose du coup la question de la migration des modules actuels du network Obeo, c’est à dire ceux qui sont publiquement disponibles. Obeo ne prévoit pas cette migration dans l’immédiat. Elle pourra être faite par la suite par le biais d’une “moulinette” qui transformera les anciens templates (.mt) dans le nouveau format (.mtl). Obeo a choisi cette méthode plutôt que d’assurer une compatibilité directe entre la version 3 et la version 2.6 actuelle.

Ce choix n’est pas surprenant pour une société dont le cœur de métier repose justement sur les “transformations”.

Quelques vidéos de démonstration sont disponibles sur le wiki Eclipse : vidéos de démonstration Acceleo.

Hier soir a eu lieu le premier PMC Obeo Network, pour Project Management Committee. Ce comité a réuni les partenaires Obeo afin de leur présenter le nouveau portail obeonetwork.org.

Cet espace communautaire va permettre aux partenaires Obeo qui le souhaitent de contribuer au “network”, et ainsi, d’enrichir le référentiel de composants publiques par des mises à jour et de nouveaux outils s’appuyant sur la technologie Obeo de transformation de modèles.

Ainsi, la page d’acceuil du référentiel de modules fournit la liste de ces partenaires.

Parmi les contributions évoquées, ProxiAD va apporter son générateur JPA, qui s’appuie sur le Méta Modèle “Entity” actuel d’Obeo. Et Capgemini apportera ses générateurs GWT et JDBC.

La rubrique “Gouvernance” du nouveau portail fournit la charte Obeo Network, ainsi que les règles de nommage et les conventions de contribution (licence, propriété Intellectuelle).
Parmi ces règles, le nom de domaine “org.obeonetwork” a été choisi et Obeo a déjà commencé le refactoring du code du network en ce sens. Attention par contre aux utilisateurs de cartouches existantes qui devront prendre en compte ce paramètre pour leurs futures mises à jour.

La partie …

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Il va de soit que les tests représentent un gage de qualité pour un projet. Leur adoption dépend à mon avis de deux aspects :

• une bonne méthodologie ;
• une infrastructure adaptée.

Si les méthodes agiles et le TDD représentent un facteur de motivation, il serait dommage de ne pas les mettre en œuvre. Si ce n’est pas le cas, ou que le projet ne s’y prête pas, l’important à mon sens est de créer un besoin. L’un des aspects essentiels du développement assisté par les tests est de fournir un maximum de confort et de possibilités aux développeurs, afin de faire du test unitaire un outil de développement apprécié et indispensable.

Quelque soit la solution choisie, sa pérennité dépend fortement de la mise en place de l’infrastructure et de l’outillage nécessaires. L’intégration continue, notamment, est capitale.

Enfin, une solution de tests fonctionnels complètera efficacement l’une ou l’autre des méthodes citées.

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Gestion des données

Pour résumer, l’objectif est ici de placer la BDD dans un état prédéfini avant le test, de façon automatique, afin d’assurer sa reproductibilité. De plus, cette initialisation doit se faire :

• de façon suffisamment rapide pour que la durée d’exécution des tests ne devienne pas une contrainte ;
• de façon suffisamment souple pour injecter facilement toutes sortes de données. En outre, une méthode d’insertion dynamique permettra par exemple de créer des listes volumineuses pour tester un composant de pagination ou de tri.

Les tests contextuels nécessitent des jeux de données plus conséquents que les tests en isolation. Malgré tout, il est important que ceux-ci restent suffisamment légers pour conserver des performances acceptables.

Pour organiser ces jeux de données de façon optimale, nous distinguerons :

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

En pratique, que l’on choisisse le TDD ou une autre méthodologie, la complexité majeure de mise en œuvre réside dans la gestion des données de tests. La problématique consiste à placer la base de données dans un état prédéfini, avant l’exécution de chaque test, de façon automatique.

Par ailleurs, la politique de gestion des données est déterminante pour choisir les outils appropriés.

En TDD, les tests unitaires sont réalisés en pure isolation. C’est-à-dire que chaque fonction est testée en l’isolant de son contexte d’exécution afin d’éviter toute interférence externe qui risquerait de compromettre le résultat du test. C’est pour cela que les implémentations “mock” comme EasyMock ou Mockito (Mockito in six easy examples) sont très utilisées en TDD. L’isolation réduit aussi considérablement le volume de données de tests à gérer. Des outils comme DBUnit et SpringUnit, qui permettent de spécifier en XML les données attendues …