Conception et développement de composants de tests unitaires de Workflow

Université de Franche-Comté Faculté de Sciences Laboratoire d Informatique de Franche-Comté Rapport du stage effectué du 9 février 2009 au 30 juin 2009 dans la société SKINsoft à Besançon Maître de stage : Nel Taurisson Tuteur universitaire : Fabrice Bouquet Conception et développement de composants de tests unitaires de Workflow Solaine Durpoix

2

Remerciements Je tiens à remercier M. Geoffroy Rigoulot et Mme Pascale Linderme pour m avoir accueillie au sein de leur entreprise dans le cadre de mon stage, ainsi que M. Nel Taurisson pour m avoir soutenue et guidée pour son bon déroulement. Bien que M. Ciprian Melian ne soit pas présent en permanence dans les locaux de SKINsoft, je tiens tout de même à le remercier pour son accueil. Concernant la rédaction de mon rapport, je suis reconnaissante à Mme Liliane Durpoix, M. Nel Taurisson et M. Fabrice Bouquet pour leur participation. 3

Table des matières Remerciements 3 Introduction 7 1 Présentation du stage 8 1.1 Présentation de l entreprise SKINSOFT............. 8 1.1.1 Son organisation..................... 8 1.1.2 Son métier......................... 9 1.1.3 Son logiciel........................ 9 1.1.4 Son partenaire : Nuxeo.................. 9 1.2 Contexte du stage......................... 10 1.2.1 Qu est-ce qu un workflow?................ 10 1.2.2 Pourquoi les workflows?................. 11 1.2.3 La mission du stage.................... 12 1.2.4 Outils utilisés....................... 13 1.2.5 Méthode de travail : SCRUM.............. 14 2 Déroulement du stage 15 2.1 Familiarisation avec le moteur de workflow jbpm....... 15 2.1.1 Présentation........................ 15 2.1.2 Les différents éléments d un workflow jboss....... 16 2.1.3 Présentation des différentes notions d un workflow jbpm à travers la description d un exemple.......... 16 2.2 Premier test : test de couverture et de détection de cycle.... 19 2.2.1 Détection de cycles.................... 19 2.2.2 Test de couverture.................... 20 2.3 Modélisation des comportements utilisateurs grâce à des mock users............................... 20 2.3.1 Définition d un Mock Object............... 21 2.3.2 Gestion des Mock Users................. 21 2.4 Second test : vérification de règles métier............ 23 4

2.4.1 Présentation du système de gestion de règles métier : Drools (ou jboss rules).................. 24 2.4.2 Principe du test...................... 25 2.5 Adaptation des tests pour les workflows Nuxeo......... 26 2.5.1 Spécification des Mock Users pour les workflows Nuxéo 26 2.5.2 Formalisation des règles grâce à un DSL........ 27 2.5.3 Présentation d un workflow Nuxeo............ 27 3 Bilan du stage 31 Conclusion 33 Glossaire 33 Webographie 35 A Test guide 36 B Nuxeo test guide 47 5

Table des figures 2.1 Exemple de workflow : relecture d articles............ 17 2.2 Décomposition d un token dans un noeud de type fork..... 18 2.3 Exemple de rapport de couverture................ 21 2.4 Diagramme de classes des utilisateurs virtuels.......... 22 2.5 Exemple de règle métier...................... 24 2.6 Exemple de workflow Nuxeo : acquisition d oeuvre(s)...... 28 2.7 Premier exemple de règles métier................. 29 2.8 Deuxième exemple de règles métier................ 30 6

Introduction Durant ma deuxième année de Master Informatique spécialité Sécurité et Sûreté du Logiciel à l Université de Franche-Comté, je dois réaliser un stage en entreprise. Celui-ci doit se dérouler sur une période de 16 semaines minimum. La société SKINsoft m a accueillie en son sein pour l y effectuer du 9 février au 30 juin. La société SKINsoft est une société de Recherche et Développement en Informatique. Son domaine de recherche est l univers des musées. Son logiciel, SKINmuseum, offre une solution de gestion de collections. Le but de mon stage est de réaliser un composant junit qui permette de tester facilement l application. Deux personnes m encadrent : mon tuteur, M. Fabrice Bouquet, Professeur à la faculté, qui a pour rôle d intervenir ponctuellement comme, par exemple, pour effectuer la visite de stage ou encore me conseiller dans l élaboration de mon rapport mon maître de stage, M. Nel Taurisson, l ingénieur Recherche et Développement de SKINsoft, qui me délivre mes objectifs et suit la progression de mon travail. Après une brève présentation de SKINsoft, je vais vous présenter le contexte de mon stage, puis son déroulement. Enfin, je vous exposerai le bilan de mon stage. 7

Chapitre 1 Présentation du stage Ce premier chapitre va me permettre d une part de vous présenter l entreprise dans laquelle j ai effectué mon stage et d autre part, le contexte de mon stage. 1.1 Présentation de l entreprise SKINSOFT SKINsoft est une société de Recherche et Développement en Informatique, créée le 1 er avril 2008. 1.1.1 Son organisation Son effectif actuel est de trois personnes : - gestion d entreprise, stratégie marketing et développement commercial : Geoffroy RIGOULOT - management : Ciprian MELIAN - ingénierie R&D : Nel TAURISSON Geoffroy Rigoulot et Ciprian Melian sont les co-gérants de SKINsoft. Geoffroy RIGOULOT dirige depuis 1986 en co-gérance avec Pascale Linderme sa propre entreprise, L AGENCE PRIVEE LRG associés, de conseil marketing et communication, en France et à l international. De plus, il est le gérant d une société de conception, fabrication et distribution de meubles contemporains pour l univers des musées : Plan Libre. Ciprian MELIAN dirige également depuis 2002 sa propre entreprise, Melian Multimedia, de services internet et multimédia. 8

1.1.2 Son métier Le domaine de recherche de SKINsoft est l univers des musées. Sa vocation est de développer un ensemble d innovations technologiques, et de nouer des partenariats avec les acteurs de ce marché pour leur permettre de disposer d une offre performante, à la pointe de la technologie. La première phase de recherche et développement de SKINsoft a abouti à la stabilisation début janvier de l application SKINmuseum. 1.1.3 Son logiciel SKINmuseum offre une solution de gestion des collections de musées riche, flexible et adaptable aux spécificités métier. Il s agit d une solution client / serveur (client accessible depuis n importe quel navigateur web, serveur multi-plateforme) qui ouvre la porte à une gestion collaborative des collections. Les bases de cet outil sont entièrement libres puisqu elles reposent sur les technologies JAVA/JEE et JBoss. L application fonctionne à l Hôtel Dieu des Hospices de Beaune, et est en phase d installation au Musée d Art et d Histoire de la ville d Auxerre. De plus, SKINsoft a décroché mi-mai le contrat d équipement du Centre National du Costume de Scène de Moulins. 1.1.4 Son partenaire : Nuxeo Alors que le logiciel n était pas encore créé, mais seulement pensé, une analyse fut faite sur le choix des technologies à utiliser. Une des premières spécifications techniques définies fut la nécessité que le logiciel soit full web. Dès lors, soit SKINsoft choisissait de développer le logiciel à partir d un framework léger type Php, soit l entreprise basait son logiciel sur une plateforme de gestion de contenu (ECM) déjà existante. L idée d utiliser php a vite été écartée car pour créer un noyau adaptable, il est nécessaire d avoir une vraie architecture composants que n offre pas les Frameworks Php existants. De plus, son mode d exécution (envoi de requêtes et de réponses) ne permet pas de développer des applications de la complexité de celles visées. Une recherche fut donc faite pour trouver un système de gestion documen- 9

taire : Nuxeo EP et Alfresco sortirent du lot. Après une analyse poussée de ces deux systèmes, Nuxeo EP, produit de l entreprise Nuxeo, fut retenu. Cette ECM permet de gérer des documents dans des processus métiers. Par exemple, les oeuvres d un musée (documents) doivent être correctement gérées lors d un prêt (processus métier) à un autre musée. Nuxeo est un éditeur de logiciels d applications Open Source dans le domaine de la gestion de contenu d entreprise et de la GED, basées sur les technologies Java EE 5. La société a été fondée en 2000 par Stéfane Fermigier. Outre le fait que leur produit soit actuellement la base de SKINmuseum, la société NUXEO ( CA de 3 millions d euros en 2008 ) est entrée au capital de SKINsoft en février 2009. Depuis, les deux sociétés mènent conjointement des actions de Recherche et Développement. 1.2 Contexte du stage Les processus métiers du logiciel SKINmuseum sont implémentés par des workflows. Dans un premier temps, je vais vous présenter le concept des workflows, puis leur rôle dans l application. Ces deux premières parties m amèneront ensuite à la description de la mission de mon stage. Le rôle de mon stage étant présenté, je vous décrirai la partie technologique du contexte de mon stage. Enfin, je conclurai en vous présentant la méthode de travail que nous avons choisi d utiliser avec mon responsable, pour mener à bien mon stage. 1.2.1 Qu est-ce qu un workflow? On appelle «workflow» (que l on traduit littéralement par «flux de travail») la modélisation et la gestion informatique de l ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d un processus métier. Le terme de «workflow» pourrait donc être traduit en français par «gestion électronique des processus métier». SKINmuseum étant destiné à des musées, les workflows qui y sont implémentés permettent de gérer des processus métiers de la muséologie tels que l acquisition d une oeuvre, ou son récolement. Les workflows sont implémentés dans Nuxeo avec la librairie jbpm éditée 10

par jboss. Comme il l a été dit précédemment (cf. 1.1.4), Nuxeo EP permet de gérer des documents dans des processus métier. Ainsi, Nuxeo a spécialisé la gestion des workflows faite par jboss pour y intégrer la gestion des documents dans les processus métier. Nous pouvons donc dire que même si la base d implémentation des workflows est celle de jbpm, Nuxeo a créé un nouveau type de workflow, que nous appelerons par la suite, les workflows Nuxeo. 1.2.2 Pourquoi les workflows? Dans la plupart des entreprises de développement de logiciels, les contrats sont définis par deux entités : - MOA : Maitrise d ouvrage, entité présente chez le client - MOE : Maitrise d oeuvre, entité présente dans l entreprise de développement La MOA n est pas souvent le vrai client du logiciel c est-à-dire le futur utilisateur, mais une sorte d intermédiaire. En effet, la MOA a pour rôle de définir, à partir des souhaits du client, les spécifications fonctionnelles du logiciel. Ensuite, elle transmet ces spécifications à la MOE, qui va se charger de les transformer en spécifications techniques et de les implémenter. Dans le monde du musée, nous pouvons identifier le client par le conservateur, et la MOA comme étant le service informatique ou un consultant du musée. Dans notre cas, la MOE correspond à SKINsoft. Une des difficultés de ce système est d arriver à définir des spécifications fonctionnelles qui soient claires pour toutes les entités. SKINsoft a donc décidé d utiliser des modèles graphiques pour formaliser les spécifications. Les spécifications fonctionnelles se décomposent chez SKINsoft en deux parties : schémas des données et des rôles processus métiers Dans un premier temps, l entreprise définissait avec ses clients les différents schémas de données (structure des différents types d oeuvres du musée, différentes permissions d accès...) à l aide d UML. Les processus métiers étaient quant à eux définis textuellement, puis définis graphiquement sans le client grâce à des workflows. La plateforme Nuxeo EP contient seulement deux workflows. Ainsi, bien que toute la gestion de documents dans les workflows soit mise au point, les workflows restent très anecdotiques dans la plateforme. Cependant, SKINsoft a fait le choix de fonder toute l implémentation de ses processus métier sur 11

cette technologie. L objectif premier de SKINsoft est donc de définir ces processus graphiquement, avec le client. De plus, l entreprise souhaiterait ajouter une spécification de règles métiers à la spécification fonctionnelle. Les règles métier (ou business rules ) sont des déclarations de haut niveau structurées, qui permettent de contraindre, contrôler et influencer un aspect du métier. A chaque processus métier peuvent être associées plusieurs règles métier. Leur but est de séparer la logique métier de la logique système ou applicatif dans une application. Ainsi la logique métier pourra évoluer et être maintenue séparément du code de l application. 1.2.3 La mission du stage Dans le logiciel SKINmuseum, l utilisation des workflows n est pas visible. En effet, c est l interface graphique qui permet de les exécuter. Ainsi, nous pourrions dire que tester les workflows revient à tester l interface graphique. Cependant, d une part, cela n est pas une bonne méthode de test et d autre part, les workflows sont souvent développés avant l interface graphique et doivent donc être testés afin de détecter des erreurs le plus rapidement possible. Néanmoins, la réalisation de tests unitaires pour les processus métiers et leur mise à jour est une tâche fastidieuse. La majorité du code de ces tests n a pour fonction que de faire tourner le workflow et doit être révisé lors de chaque modification. Le but de ce stage est donc d étudier et de réaliser des tests unitaires à partir de la représentation graphique des processus. La majeur partie du code sera un composant junit réutilisable pour tous les workflows, permettant ainsi de limiter la phase de rédaction des tests. Comme il l a été dit dans la section précédente (cf. 1.2.2), un ensemble de règles métier est défini avec le client. Ces règles doivent être absolument respectées, d une part pour assurer au client que le logiciel développé correspond bien à ses attentes et d autre part, pour vérifier tout au long du développement que l on ne s éloigne pas des objectifs définis. Ainsi, une des missions de mon stage est d une part, de trouver un formalisme de représentation des règles métiers et d autre part, d intégrer au composant junit, un test permettant de vérifier qu un workflow respecte bien un certain nombre de règles métier. Il s agit donc d utiliser les techniques de tests unitaire pour réaliser des tests fonctionnels. Cette première partie du stage va donc consister à réaliser un composant 12

junit pour les workflows de jboss. La seconde partie sera de spécialiser ce composant pour l adapter aux tests de workflows Nuxeo. 1.2.4 Outils utilisés Lors de mon arrivée chez SKINsoft, je me suis adaptée à son environnement de travail et notamment aux outils que M. TAURISSON utilisait. Système d exploitation : Linux L ordinateur à ma disposition lors de mon stage était installé avec le système d exploitation Ubuntu, construit autour du noyau Linux. Une des principales raisons qui justifie ce choix est le fait que la technologie java est plus rapide sous Linux que sous Windows. Ensuite, SKINsoft n utilise pas de logiciels non compatibles avec Linux. Environnement de développement logiciel : Eclipse Eclipse IDE est un environnement de développement intégré libre, extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en oeuvre n importe quel langage de programmation. Dans notre cas, le langage de programmation utilisé est Java. Cet environnement permet à SKINsoft de créer et de gérer l ensemble de ses projets Java à travers l utilisation de nombreux plugins tels que : Subversive : permet de gérer un SVN (Subversion) TeXlipse : permet de créer et de visualiser des documents LaTeX (utilisé pour la rédaction de ce rapport) JBoss Graphical Process Designer : éditeur graphique de workflow (processus métier) Drools : permet de gérer des règles métier plugin pour utiliser Ant, logiciel d automatisation de production de projet Logiciel d automatisation de production de projet : Maven Apache Maven est un outil logiciel libre pour la gestion et l automatisation de production des projets logiciels Java en général. Il est géré par l organisation Apache Software Foundation. Précédemment Maven était une branche de l organisation Jakarta Project. 13

Le but de cet outil est comparable à celui du système Make sous Unix : produire un logiciel à partir de ses sources, en optimisant les tâches réalisées à cette fin et en garantissant le bon ordre de fabrication. Il ajoute à ces fonctionalités une gestion puissante des dépendances entre projets. Ant est utilisé pour piloter maven en automatisant des tâches comme le build ou le déploiement vers différents environnements (test, production...). 1.2.5 Méthode de travail : SCRUM Scrum est une méthode agile pour la gestion de projets. Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s articule en effet autour d une équipe soudée, qui cherche à atteindre un but, comme c est le cas en rugby pour avancer avec le ballon pendant une mêlée. Le principe de base de Scrum est de focaliser l équipe de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de durée fixe de une à quatre semaines, appelées Sprints. Chaque Sprint possède un but à atteindre, défini par le Directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours à la livraison d un produit partiel fonctionnel. Pendant ce temps, le Scrum- Master a la charge de réduire au maximum les perturbations extérieures et de résoudre les problèmes non techniques de l équipe. Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel, et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint. Dans le cadre de mon stage, le Directeur de produit est Geoffroy RI- GOULOT et le ScrumMaster, Nel TAURISSON. La durée d un sprint est de 1 semaine (5 jours travaillés). Pour appliquer cette méthode jusqu au bout, nous avons choisi un nom pour le projet : JbpmUnit, combinaison de Jbpm et de JUnit. Vous ayant présenté le contexte de mon stage, ja vais désormais vous présenter son déroulement de manière chronologique. 14

Chapitre 2 Déroulement du stage La première partie de ce rapport m a permis de vous présenter le lieu de mon stage et la seconde, son contexte. Ce troisième chapitre, quant à lui, va me permettre de vous exposer le contenu du stage, c est-à-dire les différentes tâches que j ai effectuées chez SKINsoft au cours des quatre mois de mon stage. 2.1 Familiarisation avec le moteur de workflow jbpm Lors de mon arrivée chez SKINsoft, il me fallut découvrir les différentes technologies sur lesquelles j allais travailler. La principale et également celle que je ne connaissais pas fut celle des workflows de jboss. Je vais donc vous les présenter dans cette partie, puis je vous décrirai l exemple de workflow qui m a permis de me familiariser avec la technologie jbpm. 2.1.1 Présentation JBPM est un logiciel libre développé par JBoss, écrit en java. C est un moteur de workflows, dans lequel chaque workflow (processus métier) est décrit dans un fichier XML : définition du processus. Ce fichier décrit également les classes java utilisées pour le traitement des données (API JBPM). Un workflow étant plus explicite graphiquement, il est bien évidemment possible de le créer graphiquement. L éditeur graphique que j ai utilisé est le plugin Eclipse JBoss Graphical Process Designer. Il permet de passer d une vue graphique du processus sous forme de graphe orienté à une vue sous format XML. La synchronisation des deux vues est gérée, ainsi il est possible de modifier le fichier XML et d en voir la résultante sous format 15

graphique. 2.1.2 Les différents éléments d un workflow jboss Démarrer un workflow signifie créer et exécuter une instance du processus. Et tout comme il est possible de créer plusieurs instances d une même classe Java, plusieurs instances du même processus peuvent être exécutées en même temps. Au démarrage d un workflow, un jeton est créé. Ce jeton suit le chemin d exécution du processus et peut se décomposer en jeton fils. Cependant, les jetons ne se déplacent pas en même temps ; nous restons dans du parcours séquentiel. Il est possible de stocker des variables dans le contexte de l exécution, ainsi que sur un jeton. Ces variables permettent de manipuler les objets métiers liés au processus. Au niveau structurel, un processus est composé de noeuds et de transitions sur lesquels des actions (code Java ou script) peuvent être exécutées. Pour une meilleure compréhension des sections du rapport qui vont suivre, je vais vous présenter ces différentes notions à travers un exemple. La description de l exemple qui va suivre va vous permettre de mieux cerner la fonction de chaque élément précédemment présenté. 2.1.3 Présentation des différentes notions d un workflow jbpm à travers la description d un exemple L exemple qui me permit de me familiariser avec l implémentation des workflows est l exemple de workflow de la relecture d articles. Ce processus métier se décompose en plusieurs étapes. Un utilisateur soumet un article pour qu il soit relu et ensuite, choisit un ensemble de relecteurs. Chacun des relecteurs a pour rôle d attribuer une note à l article. Une fois que l article a été noté par tous les relecteurs, sa moyenne est calculée. Il est possible de soumettre plusieurs articles. Lorsqu il n y a plus d articles à soumettre, une sélection est faite de telle sorte que seuls les articles qui ont une moyenne supérieure à 10 sont sélectionnés. Cet exemple va me permettre de vous présenter les différentes notions des workflows jbpm. Je vais vous présenter le workflow à travers la description de son exécution (cf. figure 2.1). 16

Fig. 2.1 Exemple de workflow : relecture d articles. Le processus démarre par le noeud start de type start-state. Un graphe doit posséder exactement un noeud de ce type pour permettre au processus de démarrer. Comme il l a été dit précédemment, le token / est créé au démarrage du processus et parcourt l ensemble des noeuds et des transitions du graphe. Le premier élément qu il parcourt, après le noeud start, est la transition starttosubmission. Une transition est un arc orienté qui permet de faire passer un jeton d un noeud à un autre. Autre que le noeud de type start-task, notre exemple de graphe est constitué de quatre autres types de noeuds : task-node : ce type de noeuds représente une ou plusieurs tâches qui doivent être exécutées par un utilisateur. Par exemple, le noeud submission représente la soumission d un article par un utilisateur. Tant que cet utilisateur n aura pas valider la soumission, l exécution du processus sera en attente sur ce noeud. Ces tâches représentent le plus souvent des actions effectuées sur une 17

Fig. 2.2 Décomposition d un token dans un noeud de type fork. interface graphique reliée au workflow. Lors de l implémentation de ce workflow, n ayant pas mis au point d interface graphique, j ai créé une fonction pour chaque tâche de chaque task-node dans la classe de test. Cette méthode de test est très statique mais était suffisante dans un premier temps. join : lorsqu un jeton arrive sur ce noeud, il y est bloqué tant que tous les jetons qui ont le même parent que lui ne sont pas arrivés. Une fois qu ils sont tous arrivés, le noeud termine l exécution de chaque jeton fils et c est le parent qui continue l exécution. Ce noeud permet ainsi de rassembler un ensemble de chemins d exécution. end-state : c est le dernier noeud d un graphe : dans cet exemple, c est le noeud end. Il peut y en avoir plusieurs dans un même graphe, mais dès que l on arrive sur l un de ces noeuds, l exécution s arrête. node : ce type de noeud est utile lorsque l on veut exécuter du code Java. Le noeud final list of articles est un noeud de ce type dont l action permet de ne sélectionner que les articles qui ont une moyenne supérieure à 10. Un autre type de noeud existe mais n est pas utilisé dans cet exemple : Fork. Contrairement à un noeud de type Join, ce type de noeud permet de découper un chemin d exécution. Un token fils, de celui entré dans le fork, est créé pour chaque transition qui quitte le noeud (cf figure 2.2 : le token / se décompose en trois sous-token t1, t2 et t3 qui deviennent ses fils). Pour implémenter la logique métier du processus, comme par exemple calculer la moyenne d un article, des actions sont implémentées. Les actions Une action est un bout de code Java qui est exécuté lors de l exécution du processus. Les actions permettent d ajouter des détails techniques en dehors de la 18

représentation graphique : le code Java peut être associé au graphe sans changer la structure du graphe. Les actions sont généralement placées sur des événements : - événement sur un noeud (tous types) : node-enter (entrée sur le noeud), node-leave (sortie du noeud) - événement sur une transition : transition - événement sur un noeud de type task-node : task-start (démarrage d une tâche), task-create (création d une tâche), task-assign (assignation d une tâche à un utilisateur) et task-end (fin d une tâche). Un événement de ce type sera déclenché pour chaque tâche du noeud. - événement sur le processus : process-start (démarrage du processus) et process-end (fin du processus) Cependant, il est également possible de les placer directement sur un noeud comme cela est fait pour le noeud final list of articles : les actions sont exécutées lorsqu un token arrive sur le noeud. Cet exemple nous montre que nous ne sommes pas limités à l utilisation des seuls noeuds jbpm. En effet, pour créer les noeuds fork :each reviewer et join :each article, j ai repris les fonctionalités du fork et du join et j y ai ajouté ce dont on avait besoin et qui n était pas géré par le fork et le join de jbpm. Ayant cerné la plupart des notions des workflows jbpm, j ai pu débuter la principale mission de mon stage, c est-à-dire tester ces workflows. 2.2 Premier test : test de couverture et de détection de cycle. Ce premier test se décompose en deux parties : le test de détection de boucles et le test de couverture. 2.2.1 Détection de cycles La première partie du test consiste à détecter s il y a des boucles dans un workflow. Pour ce faire, une action est ajoutée automatiquement sur chaque transition (événement transition) et sur chaque noeud du workflow (événement nodeenter), avant le démarrage de l exécution du processus. L action ajoutée a pour but d augmenter le compteur du noeud ou de la transition où est placée 19

l action. Ainsi, dès qu un token passe une transition (ou entre dans un noeud), l action se déclenche et le compteur de la transition (ou du noeud) augmente. Ayant un moyen de connaître le nombre de passages dans une transition ou dans un noeud, il reste à définir à partir de combien de passages il faut considérer qu une boucle doit être détectée. Ce choix est laissé au testeur. Au déclenchement de l action, si le compteur maximum est atteint pour une transition ou un noeud, le test échoue en précisant l endroit ( noeud ou transition ) où se situe la boucle. De plus, il est possible de configurer ce test pour qu il attribue un compteur à chaque token qui passe sur chaque noeud et chaque transition. Par exemple, si deux tokens passent sur un noeud, alors ce noeud possèdera deux compteurs : un pour chaque token. Cela permet donc d affiner le test de bouclage. 2.2.2 Test de couverture A la fin du test de bouclage est affiché un rapport de couverture des noeuds et des transitions du graphe. Cela consiste simplement à récupérer les compteurs de l ensemble des noeuds et des transitions et à les afficher (cf. figure 2.3). Le test de couverture permet de détecter si un noeud ou une transition n est jamais visité(e). Si au moins un noeud ou une transition n est pas visité(e), le test devient KO (cf. figure 2.3). Ce test n est pas réellement un test puisque si un noeud n est pas visité, le test junit n échoue pas ; c est la raison pour laquelle il se trouve à la fin du test de détection de boucles et n est pas un test indépendant. 2.3 Modélisation des comportements utilisateurs grâce à des mock users Comme il l a été précisé dans la partie 2.1.3, pour faire tourner l exemple de workflow qui m a permis de me familiariser avec jbpm, j ai dû créer des méthodes pour chaque tâche de chaque noeud de type task-node. Cette technique est très statique et ne donne pas la possibilité au testeur d attribuer des actions différentes pour une même tâche et de tester le workflow avec plusieurs utilisateurs. L idée fut alors de trouver un formalisme de description et d implémentation de comportements utilisateurs. 20

Fig. 2.3 Exemple de rapport de couverture. 2.3.1 Définition d un Mock Object En programmation orientée objet, les mock objects sont des objets virtuels qui imitent le comportement de vrais objets. Ils sont généralement créés pour tester le comportement d autres objets. Dans notre cas, le testeur crée des utilisateurs virtuels pour tester la structure et le fonctionnement du workflow. 2.3.2 Gestion des Mock Users A partir du moment où un workflow contient au moins un noeud de type task-node, il est nécessaire de créer des utilisateurs virtuels pour le tester. Il existe deux types d utilisateurs virtuels (cf. figure 2.4). 21

Le premier type est DefaultMockUser : ce type de Mock User correspond, comme son nom l indique, à un Mock User par défaut. Il se contente de terminer la tâche. Donc ce type de Mock user convient pour des tâches qui n ont pas d influence sur le reste de l exécution du workflow, comme par exemple, une tâche où l utilisateur aurait juste un formulaire à remplir et que ce formulaire ne serait jamais consulté par la suite. Le deuxième type de Mock User est à l inverse du premier totalement configurable : AbstractMethodBasedMockUser. En effet, cette classe Java est abstraite et demande à être implémentée par une ou plusieurs classes filles. Implémenter les classes filles signifie y créer des méthodes pour les tâches. Nous restons ainsi dans le principe de départ qui consistait à créer une méthode pour chaque tâche du workflow. La grande différence est qu il est désormais possible d en créer plusieurs pour une même tâche et dans des Mock Users différents. Ainsi, deux classes filles peuvent contenir des méthodes pour la même tâche. Fig. 2.4 Diagramme de classes des utilisateurs virtuels. Le testeur peut créer autant d utilisateurs virtuels qu il le souhaite de chacun des deux types. Choix d un utilisateur virtuel Par défaut, lorsqu un jeton arrive sur un noeud de type task-node, un utilisateur virtuel est choisi presque au hasard parmi ceux créés par le testeur. En effet, si l utilisateur choisi est de type AbstractMethodBasedMockUser, une vérification est faite pour savoir s il possède ou non une méthode compatible pour la tâche. Si ce n est pas le cas, un autre utilisateur est choisi. En revanche, si l utilisateur est du premier type, rien ne peut empêcher ce 22

choix. Cependant, comme il l a été dit précédemment, les utilisateurs de type DefaultMockUser doivent être utilisés seulement pour des tâches dont l action n a pas d incidence sur le reste du workflow. Dans le cas contraire, cela peut poser problème pour le reste de l exécution du workflow. Pour pallier ce problème et pour laisser la possibilité au testeur de créer en même temps des utilisateurs des deux types, deux listes ont été attachées à chacun des deux types. Ces listes sont destinées à contenir des noms de tâches et ont été créées sur le principe de liste noire (LN) et de liste blanche (LB) : si une tâche se trouve dans LB et pas dans LN, alors elle est acceptée si une tâche se trouve dans LB et dans LN, elle est refusée si LB est vide, toutes les tâches ne se trouvant pas dans LN sont acceptées si LB n est pas vide et qu une tâche ne se trouve dans aucune des deux listes, alors elle est refusée. Le testeur peut ainsi remplir les listes de chacun de ses utilisateurs virtuels comme il le souhaite. Par exemple, si une tâche du workflow ne doit absolument pas être effectuée par un utilisateur de type DefaultMockUser, il doit ajouter le nom de cette tâche dans la liste des tâches non acceptées (boite noire) de chacun des utilisateurs qui sont de ce type. Choix d une méthode Le nom des méthodes implémentées dans un Mock User doit suivre une syntaxe très particulière : task{nomtâche}{nomméthode}. C est cette syntaxe qui va permettre la sélection d une méthode pour une tâche. Cette sélection est aléatoire. Une autre configuration est possible : elle concerne le choix des utilisateurs virtuels et celui des méthodes. Ces choix peuvent être avec ou sans remise, c est-à-dire que si un utilisateur a été choisi, il ne sera plus choisi tant qu il y aura encore d autres utilisateurs compatibles avec la tâche et qui n ont jamais été sélectionnés. Il en est de même pour le choix des méthodes. L intérêt de cette configuration est de tester au maximum le workflow. 2.4 Second test : vérification de règles métier Le premier test qui a été implémenté permet de tester la structure d un workflow. Le second a, quant à lui, pour but de le tester fonctionnellement en vérifiant qu il respecte bien un certain nombre de règles qui doivent être 23

définies avec le client. 2.4.1 Présentation du système de gestion de règles métier : Drools (ou jboss rules) Drools (ou JBoss Rules) est un système de gestion de règles métier (ou SGRM) utilisant un moteur d inférence à chaînage avant. C est un logiciel libre distribué selon les termes de la licence Apache. Un moteur d inférence permet aux systèmes experts de conduire des raisonnements logiques et de dériver des conclusions à partir d une base de faits et d une base de connaissances. La base de faits est, dans notre cas, la logique métier implémentée dans le workflow et la base de connaissances correspond aux règles métier. Travaillant sur des workflows jbpm, il fut assez logique de choisir le SGRM du même serveur d applications. De plus, ce SGRM est écrit en Java. Les règles métier implémentées dans Drools se décomposent en deux parties distinctes : when : partie d une règle où sont définies les différentes conditions qui doivent être vérifiées. La syntaxe des conditions est particulière dans le sens où c est le constructeur d un objet qui est utilisé pour définir la condition. Les règles permettent ainsi de tester les attributs d objets Java. then : partie d une règle qui n est exécutée que lorsque les conditions définies dans le then sont respectées. Le code écrit dans cette partie est du code Java. La figure 2.5 montre un exemple de règle métier qui teste un objet de la classe Message. L attribut status est testé et l attribut message est récupéré (usage de : ) et mis dans une variable message. Cette variable est ensuite affichée si la condition n est pas respectée. Fig. 2.5 Exemple de règle métier. 24

Plus simplement, cette règle permet d afficher la proriété message d un objet de type message lorsque sa propriété status a pour valeur Message.GOODBYE. Pour pouvoir définir des conditions sur des objets Java, ceux-ci doivent au préalable être insérés dans le moteur avant son lancement. 2.4.2 Principe du test Vérifier qu un workflow respecte des règles métier revient à vérifier que la logique métier du processus est correct. Ainsi, les règles métier travaillent sur les objets métier liés au processus et donc sur les variables du contexte du workflow (cf. section 2.1.2). Etant donné que le contexte du processus change après chaque déplacement d un jeton ou chaque exécution d une action, il n est pas suffisant de ne vérifier qu une seule fois le respect des règles, comme par exemple à la fin de l exécution du processus. Ainsi, avant le démarrage du workflow, la définition du processus est automatiquement modifiée de telle façon qu une action est ajoutée sur tous les événements existants pour chaque élément du workflow. Sur certains événements, l action est ajoutée avant toutes les autres actions de l événement et sur d autres, elle l est après. Cela permet de vérifier le respect des règles avant ET après l exécution d une ou plusieurs actions. événements sur lesquels l action est ajoutée avant toutes les autres : node-enter, task-create, task-start, task-assign événements sur lesquels l action est ajoutée après toutes les autres : node-leave, transition, task-end L action qui est ajoutée a pour but de lancer le moteur d inférence du SGRM sur le fichier de règles. Avant d effectuer ce lancement, les variables du contexte sont insérées dans la session du moteur de règles. Ces variables représentent ainsi la base de faits que le moteur va comparer à la base de connaissances que représentent les règles métier. Lorsqu une règle n est pas respectée, le code Java du when est exécuté. La personne qui effectue ce test est également celle qui écrit le fichier de règles. Ainsi, elle a le choix entre faire échouer le test junit ou simplement afficher un message signalant le non-respect de la règle. A ce stade du rapport, la première partie de mon stage est terminée puisque la première version du composant junit est en état de marche. Ce composant se nomme JbpmUnit. J ai réalisé une documentation, pour l utilisation du composant junit, qui se trouve en annexe A. 25

La deuxième partie du stage consiste à spécialiser ce composant pour qu il permettre de tester des workflows Nuxeo. Cette spécialisation résulte donc en un nouveau composant intitulé JbpmUnitNuxeo. Sa documentation se trouve en annexe B. Dans la section suivante, je vais vous présenter la spécialisation de JbpmUnit. 2.5 Adaptation des tests pour les workflows Nuxeo La principale différence entre les workflows basiques de jbpm et ceux de Nuxeo est la gestion de documents. En effet, Nuxeo a intégré à sa plateforme une sur-couche à l implémentation des workflows jbpm. Cette sur-couche permet à tout utilisateur de leur plateforme de créer des workflows consacrés à la gestion de documents, comme c est le cas pour SKINsoft. Mon responsable et moi avons choisi de dissocier le test de workflows jbpm de celui de workflows Nuxeo. Un nouveau composant de test fut alors créé : JbpmUnitNuxeo. Cependant, bien que les deux tests soient dissociés, les composants ne le sont pas complètement puisque JbpmUnitNuxeo spécialise JbpmUnit. 2.5.1 Spécification des Mock Users pour les workflows Nuxéo Dans un workflow, une tâche doit généralement être assignée à un ou plusieurs acteurs. Une convention pour l assignation des tâches a été mise en place dans la plateforme Nuxeo ; une tâche peut être assignée de trois manières différentes : assignation à un utilisateur U : user :U assignation à un groupe d utilisateurs G : group :G assignation à une permission P : permission :P Les Mock Users ont donc été spécifiés pour y intégrer cette convention. Le testeur, après avoir créé un mock user, doit lui attribuer un utilisateur Nuxeo de type NuxeoPrincipal. Il est possible d ajouter cet utilisateur à un groupe et de lui attribuer différentes permissions sur des documents. Cette spécification est présente uniquement dans le composant JbpmUnit- Nuxeo. Lors de la sélection d un mock user, un test permet de savoir si l utilisateur 26

virtuel choisi peut ou non exécuter la tâche. Ce test consiste tout d abord à récupérer l ensemble des éléments associés à l utilisateur Nuxeo du mock user sélectionné, et ceci en suivant la convention Nuxeo : le nom de l utilisateur Nuxeo est récupéré et préfixé par user : chacun des groupes dont fait partie l utilisateur Nuxeo est précédé par group : chacune des permissions attribuées à l utilisateur Nuxeo est précédée par permission : Ensuite, le test consiste à vérifier parmi l ensemble récupéré, si au moins un des acteurs de la tâche s y trouve. Si c est le cas, ce test est validé et un second test est alors exécuté : vérifier s il existe une méthode pour la tâche (cf. section 2.3.2 ). 2.5.2 Formalisation des règles grâce à un DSL Comme il l a été présenté dans la section 1.2.2, un des souhaits de SKINsoft était de pouvoir définir les règles métier avec le client, avant l élaboration du workflow. Pour rendre cette tâche plus simple, un langage dédié (DSL) fut mis au point. Dans notre cas, un DSL consiste, à partir d un ensemble de règles de réécriture proche du langage naturel, à générer du langage Drools. Voici un exemple simple de règles de réécriture du DSL : logobject object = System.out.println(object) ; Avec cette règle, le logobject sera réécrit textuellement par un System.out.println. Fonctionnellement, elle permet d afficher un objet Java. 2.5.3 Présentation d un workflow Nuxeo L exemple de workflow que je vais vous présenter correspond à l acquisition d une ou plusieurs oeuvre(s) dans un musée (cf. figure 2.6). Ce workflow est un workflow de gestion documentaire : il permet de gérer des oeuvres qui sont des documents, au sein d une acquisition qui elle-même est un document. De façon générale, les workflows Nuxeo sont liés à la gestion documentaire et permettent de : - créer un ou des documents - lier des documents par des relations - contrôler les propriétés des documents 27

Fig. 2.6 Exemple de workflow Nuxeo : acquisition d oeuvre(s). - modifier le cycle de vie des documents Dans notre exemple, au commencement du workflow, le document acquisition est dans le cycle de vie project et à la fin, il sera dans celui validé. Gestion des permissions Ce workflow comprend trois noeuds de type task-node qui se composent chacun d une seule tâche. Tous les utilisateurs ne peuvent pas réaliser une acquisition : la tâche de modification de l acquisition est une tâche que le musée peut choisir de déléguer. en revanche, la validation de l acquisition et l explication du refus de la validation sont des tâches qui doivent être réalisée par un responsable du musée, en général, le conservateur. Ce workflow se compose donc de deux permissions différentes : inventorier(employé du musée ou personne extérieur) et inventorymanager(responsable du musée), auxquelles sont assignées les tâches. Pour tester ce workflow, deux utilisateurs virtuels furent donc créés, chacun possédant une des deux permissions précédentes. 28

Mise en place de règles métier Un certain nombre de règles métier ont été implémentées afin de tester fonctionnellement le workflow. Au départ, le DSL mis en place ne comprenait que les règles de base. Il fut ensuite enrichi, au fur et à mesure des besoins lors de l écriture des règles métier. Deux règles métier ont été mises en place pour tester le cycle de vie des documents. La première règle est placée sur l événement node-enter du noeud modifier l acquisition. Elle récupère le document de l acquisition qui a été créé lors du démarrage du workflow, puis teste son cycle de vie (cf. 2.7). Fig. 2.7 Premier exemple de règles métier. La seconde règle est placée sur l événement node-enter du noeud acquisition validée. Tout comme la première, elle récupère le document de l acquisition. Le test du cycle de vie se trouve dans la partie when ; ainsi si le document n est pas dans le cycle de vie inventoried, la règle ne se déclenchera pas. Ensuite, dans la partie then se trouve le test du cycle de vie des documents correspondant à toutes les oeuvres qui doivent être acquises. Pour ce faire, deux règles ont été mises en place dans le DSL qui permettent de récupérer des documents à travers l exécution d une requête NXQL (langage de requêtes de Nuxeo). La première permet d ajouter, à la requête, des paramètres qui seront insérés dans la requête à la place des points d interrogation (cf. figure 2.8). Il n est pas obligatoire d écrire les règles entièrement avec le DSL. En effet, il est possible d y intégrer du code Java, qui doit cependant être précédé de > pour être reconnu comme du non DSL. 29

Fig. 2.8 Deuxième exemple de règles métier. 30

Chapitre 3 Bilan du stage Contrairement à mon stage de Licence 3, à mon arrivée chez skinsoft, tout était défini et je savais exactement ce que j allais faire pendant plusieurs semaines. En effet, mon stage était découpé en itérations. La première itération a consisté à me familiariser avec les différents outils qu utilise SKINsoft. Cette tâche fut aux premiers abords difficile car je ne connaissais ni les workflows jbpm, ni l outil Maven. Cependant, avec l aide de mon responsable, elle se révéla moins compliquée qu elle n en avait l air. Ensuite, une fois les notions appropriées, la continuité du stage se déroula normalement et même plutôt rapidement. En effet, j ai eu terminé l implémentation des composants junit au bout de trois mois. Ce ne fut en aucun cas une mauvaise chose puisque j ai pu découvrir une partie de l application SKINmuseum. En effet, jusqu alors, je n avais pas du tout travailler dessus. Le travail qui me fut confié était de créer des workflows pour l application et ensuite d utiliser le composant junit que j ai réalisé pour les tester. J en retire une certaine fierté puisqu il fonctionne en grandeur nature. Ainsi, mon travail a porté ses fruits. Un autre avantage de cette avance fut le fait que j ai pu commencer tôt la rédaction du rapport et ainsi ne pas être bousculée pour la terminer. Etant donné que mi-juin la date d installation de SKINmuseum au Musée d Art et d Histoire d Auxerre approchait, j ai également pu prendre part à la phase de récupération des données qui est la dernière étape avant l installation du produit. Je ne retire de ce stage que des points positifs. J ai appécié le côté familial chez SKINsoft et également la diversité d activités qui s opèrent dans les locaux puisque c est le lieu de travail de trois sociétés aux activités différentes : SKINsoft, L Agence Privée et Plan Libre. 31

Du point de vue du travail, c est également le cas, je ne trouve pas de point négatif étant donné que j ai réalisé des choses intéressantes, rentrant dans le cadre de ma formation mais ayant également une part d inconnu. J ai ainsi eu l occasion d apprendre un certain nombre de choses. 32

Conclusion Actuellement, on peut dire que tous les objectifs de mon stage ont été atteints puisque le composant junit que j ai réalisé fonctionne et que j ai moi-même pu tester son fonctionnement sur l application SKINmuseum. Mon stage chez SKINsoft fut agréable de part l ambiance qui règne dans les locaux. De plus, il fut très instructif et très enrichissant pour moi, mais également pour l entreprise à qui j ai pu apporter mes compétences en test. Mon responsable a d une part apprécié mon travail et ma rapidité d adaptation. Après une discussion entre Nel Taurisson, Ciprian Melian et Geoffroy Rigoulot, la décision fut donc prise de m embaucher pour continuer cette collaboration. Mon stage s étant très bien déroulé, j ai accepté cette offre d embauche qui va me permettre d entrer dans la vie active après une formation de cinq années après le baccalauréat. Je remercie donc Geoffroy Rigoulot et Ciprian Melian pour cette confiance qu ils m accordent. 33

Glossaire full web Outil qui permet de se connecter à son système d information à partir de n importe quel terminal relié à internet. 6 DSL En anglais Domain Specific Language, un DSL est un langage dédié. En informatique, on distingue deux types de langages : les langages généralistes (General Purpose Languages) comme PL/1, Ada ou UML, et les langages dédiés (Domain Specific Languages ou DSL) comme Excel. 25 muséologie La muséologie est une science qui s applique à tout ce qui concerne les musées, leur histoire, leur mission et leur organisation. 8 méthode agile Les méthodes agiles sont des procédures de conception de logiciel qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. 12 récolement le récolement est l opération qui consiste à vérifier, sur pièce et sur place, à partir d un bien ou de son numéro d inventaire : la présence du bien dans les collections, sa localisation, l état du bien, son marquage, la conformité de l inscription à l inventaire avec le bien ainsi que, le cas échéant, avec les différentes sources documentaires, archives, dossiers d oeuvres, catalogues. 8 UML En anglais Unified Modeling Language (=language de modélisation unifié), UML est un langage graphique de modélisation des données et des traitements.. 9 34

Webographie Documentation Java de jbpm : http://docs.jboss.org/jbpm/v3/ javadoc/ Guide utilisateur de jbpm : http://docs.jboss.org/jbpm/v3/userguide/ index.html Document Java de jboss Drools : http://hudson.jboss.org/hudson/ job/drools/lastsuccessfulbuild/artifact/trunk/target/javadocs/stable/ drools-api/index.html Guide utilisateur de jboss Drools : http://hudson.jboss.org/hudson/ job/drools/lastsuccessfulbuild/artifact/trunk/target/docs/drools-expert/ html_single/index.html Documentation Nuxeo : http://doc.nuxeo.org/5.1/books/nuxeo-book/ html/ Tutoriel Latex : http://www.ukonline.be/programmation/latex/tutoriel/ index.php 35

Annexe A Test guide Cette première annexe vous présente le guide utilisateur du premier composant de test : le composant JbpmUnit. Ce guide a été rédigé en anglais en raison de la portée générale de ce qui a été développé. En effet, ces composants ont pour vocation à être partagé de façon libre et large. 36

JbpmUnit guide Realized by Solaine DURPOIX. June 9, 2009

Contents 1 Tests presentation 39 2 Your work 39 2.1 Tests methods implementation.................. 39 2.2 MockUser............................. 40 2.2.1 DefaultMockUser..................... 40 2.2.2 AbstractMethodBasedMockUser............. 41 2.2.3 MockUsers creation : implementation of setupmockuser 42 2.3 Loop tests configuration..................... 43 2.4 Business rules tests configuration................ 43 2.5 Additional configuration..................... 43 2.5.1 Creation of a file test.handler.config.properties.... 43 2.5.2 Replace a handler in the workflow............ 45 List of Figures 1 Example of JUnit tests method.................. 40 2 MockUser management...................... 41 3 Implementation of the method SetUpMockUser......... 42 4 A configuration example...................... 44 5 Example of tests class....................... 46 38

1 Tests presentation Currently, it exists four tests : - the first detects infinite loops in the workflow : counters are added on nodes and transitions and when a counter is greater or equal than counter maximum, a loop is detected. The counter maximum is given in a file.properties. Furthermore, this test displays the coverage report on nodes and transitions. If the test succeeds, counters of all nodes and transitions will be displaying, else only those which are between node-start and node where is detected the loop, are displayed. - the second makes the same thing but with more precision : it takes account of each token which passes on a node so there is a counter for each of these tokens. This test is contained in the first test but you re not obliged to execute it (see 2.3). - and the third puts a handler of business rules verification, on each event of each node, task and transition. Reminder : A node has the different events node enter and node leave ; a task has task create, task start, task end and task assign ; a transition has transition. The two first tests correspond to structural tests and the last to the functional test. 2 Your work General implementation of tests is written in the JAR file, but you have to define some parameters of these tests. The principal tests class is AbstractJbpmUnitTestCase. Parameters definition will be realized in different abstract methods of this class (see 5). 2.1 Tests methods implementation You have the choice between to realize tests on one workflow or on several. one workflow : your tests class must inherit the class AbstractOne- ProcessJbpmUnitTestCase. This class inherits AbstractJbpmUnitTest- Case so you will have to implement different abstract methods of this 39

class. One of these is getprocessurl : in this method, you must return your workflow s url (xml file). In your tests class, you don t need to write tests method. You must only configure your test in calling methods setlooptest and setruletest. several workflow : your tests class inherits directly the class AbstractJbpmUnitTestCase. So you must define JUnit tests methods. In a tests method, you have to create a process instance for each workflow and then, configure your test like before-mentioned. Finally, you must call the runprocesstest to run the test. Figure 1: Example of JUnit tests method. 2.2 MockUser Tasks execution depends to users behaviour and so, a MockUser permits to simulate these behaviours. The figure 2 shows our MockUsers management. The abstract super class AbstractMockUser contains two abstract methods : boolean iscandidate (TaskInstance) : tells if the mockuser contains a method for the taskinstance void executetask (TaskInstance) : executes the task Like these two methods are abstract, they are implemented in child classes MethodBasedAbstractMockUser and DefaultMockUser. 2.2.1 DefaultMockUser This class permits to not implement MockUsers. This is the implementation of both methods : boolean iscandidate (TaskInstance) : return true at any time void executetask (TaskInstance) : end the task and enter on a transition leaving the tasknode 40

Figure 2: MockUser management. These implementations permits to execute tasks and so to run the workflow, without MockUser. This MockUser type must be used only for tasks which have any influency on the rest of workflow. 2.2.2 AbstractMethodBasedMockUser This is the implementation of both methods : boolean iscandidate (TaskInstance) : return true if the MockUser contains methods for the taskinstance ( methods name begins with tasknomtask} ) else return false. void executetask (TaskInstance) : do a random search for a method compatible with the task. Your role is to implement different classes which inherit of this class and which represent different tasks users. These classes contain only different methods for tasks and a constructor where you can initialize different variables for tasks methods. These methods are the only methods which can t be generalized. In fact, tasks behaviours are different according to the workflow. Like we tell previously, their name is specific : task{nomtask}{methoddescription}, for example taskreviewerdefinecounter with reviewer the task s name and definecounter the method s name. This syntax is very important for tests execution. The task s name must be modified in the method s name : accents, spaces and dashes must be deleted. Like a task can have different behaviours, it s better to implement different method for a same task. 41

2.2.3 MockUsers creation : implementation of setupmockuser In conclusion, you have two possibilities : - to test rapidly your workflow and so to use DefaultMockUser - to test your workflow in implementing different child classes of the class AbstractMethodBasedMockUser Whatever your choice, you must implement the abstract method setup- MockUser in your test class. The figure 3 shows an example of implementation. In first, you have to create MockUser objects and add them in the MockUser list with the method addmockuser. Figure 3: Implementation of the method SetUpMockUser. The AbstractMockUser class contains two tasks list : one brings together tasks which are accepted for the current MockUser and one for tasks which aren t accepted. Presently, the MockUser choice in the MockUser list is random. And like some of tasks can t run with a DefaultMockUser (because for example, some workflow s variables must be modified in the task- Instance), these lists permits to autorize (or not) a task for a mockuser. Methods addnotacceptedtask(string taskname) and addaccepted- Task(String taskname) called on a MockUser object, adds the task in lists of this MockUser. You aren t obliged to add all tasks in all lists. In fact, we consider that a task is accepted if : - it s in the accepted tasks list and not in the not accepted tasks list - or it isn t in the not accepted tasks list and the accepted tasks list is empty 42

In other cases, the task isn t accepted for the mockuser (this test is done in the method iscandidate ). A large number of choice is done and by defect, chosen object is put away in the list. But, you can configure it : - setputawaymockuser(boolean) : configure the MockUser choice - setputawaymethod(boolean) : configure the task s method choice into a MockUser - setputawaytransition(boolean) : configure the transition choice into the DefaultMockUser (see method executetask 2.2.1) 2.3 Loop tests configuration In the first test, you have the choice of execute or not execute the part which concerns tokens. You have to exprim your choice in implementing the method executelooptesttoken. 2.4 Business rules tests configuration This section concerns the configuration of last test. At first, you must give file s url of business rules with method geturlrulesfunctionaltest. A DSL has been created, so if you want to use it in your business rules file, this one must have the extension.dsrl. In the other case, it must have the extension.drl. When a business rule isn t checked, we have the choice between to fail the test and just to indicate this fail. To write an error without stopping the test, we use a log whom you have to give a name in the method getloggername. This log will be the same for all handlers. 2.5 Additional configuration 2.5.1 Creation of a file test.handler.config.properties You aren t obliged to create this file. In fact, if you don t make it, tests will be configured with the file.properties contained into the JAR file, but if you make it, it s important that you call it : test.handler.config.properties. The property fail.loop tells if it s worth true, that tests will fail when a loop will be detected and if it s worth false, that there will be only display 43

of a message and test will continue. For the property countermax, there is three possible configurations : - configuration by process : a workflow can make reference to an other workflow, so when we test it, we can attribute a countermax for the principal workflow and a different countermax for its sub-workflow. NomProcessDefinition.counterMax=value - configuration by node : nodes countermax can be different NomProcessDefinition.NomNode.counterMax=value - general configuration : the property countermax is valid for all nodes of all workflow. countermax=value If you create this configuration file, this into the JAR file will be nevertheless taken account. In fact, properties of all configuration files which are into the classpath where are called tests, will be bring together in an object Properties. Currently, the value of countermax in the general configuration file is 10. If you define it again in your configuration file, it s your configuration which will be taken account (cf. figure 4 ). You must give your file s url with the method geturlpropertiesfile. Figure 4: A configuration example. 44

2.5.2 Replace a handler in the workflow Before you execute your tests, you can modify the handler of a class in the workflow. For that, three methods exists, one by handlers type : setreplacementactionhandler(string,class) : replace an action handler setreplacementdecisionhandler(string,class) : replace a decision handler setreplacementdecisionhandler(string,class) : replace an assignment handler The first parameter corresponds to the old handler name but can be a regular expression like * and for this example, all handlers will be replaced by the handler defined by the second parameter. 45

Figure 5: Example of tests class. 46

Annexe B Nuxeo test guide Cette deuxième annexe correspond à une extension du premier guide, qui présente la manière dont doit être utilisé le second composant : JbpmUnit- Nuxeo. 47

Extension of JbpmUnit guide : NuxeoJbpmUnit guide Realized by Solaine DURPOIX. June 9, 2009

Contents 1 Introduction 50 2 Super class 50 3 MockUsers : setupmockusers 50 List of Figures 1 Class diagram MockUsers..................... 51 2 Example of Nuxeo mock user s constructor............ 51 49

1 Introduction This document concerns tests of Nuxeo workflows and is an extension of test guide of JbpmUnit. So, that will be then presented corresponds differences between the implementation of default workflows tests and these of Nuxeo workflows. 2 Super class The super class of your tests class is nt AbstractJbpmUnitTestCase any more, but it s AbstractNuxeoJbpmUnitTestCase. So, you can t use the class AbstractOneProcessJbpmUnitTestCase. Furthermore, you don t have to implement the method getprocessurl. In fact, in Nuxeo application, workflows are stocked in the jbpmservice. So, in your tests methods, you have just to configure your test and to call the method runprocesstest ( String process, String initiatorid, DocumentModel document, Map variables, Map transientvariables ). The initiator is a NuxeoPrincipal and corresponds to workflow s initiator. 3 MockUsers : setupmockusers If you create a mock users class, it must inherit AbstractNuxeoMockUser (see 1). Function of this class is to attribute a principal to each mock user and to manage permissions. In fact, the method iscandidate is overloaded in AbstractNuxeoMockUser, to test an additional thing : task s actors must have permission to use a mock user and so, actors and mock user s principal must have a same permission. Constructors of your mock users class must overload the super class constructor and so it must have a NuxeoPrincipal and a CoreSession like parameters ( see 2 ). In your tests class, you can retrieve your mock users ( getmockuser ) and attribute them permissions ( addpermission ) or add them in a group ( addmockuserprincipaltogroup ). 50

Figure 1: Class diagram MockUsers. Figure 2: Example of Nuxeo mock user s constructor. 51

Résumé Mon stage de deuxième année de Master Informatique s est déroulé dans la société SKINsoft, à Besançon. Durant ce stage, j ai eu à concevoir et développer des composants junit pour le test unitaire de workflow. Ce stage s est révélé très positif. J ai pu mettre en pratique les différentes connaissances que ma formation m a apporté et également découvrir de nouvelles notions, notamment sur les processus métier et leur gestion informatique. Mots-clés junit, test, workflow, processus métier, règle métier Abstract My industrial placement of Computing Sciences Master s second year took place in the company SKINsoft, to Besançon. During my industrial placement, I realised junit components for unit test of workflows. This industrial placement went very well. It was the occasion for me to put into practise the knowledge I learned during my curriculum. It made me discover new notions pertaining, for example, to business process modelling and management. Keywords junit, test, workflow, business process, business rule