Pour les fêtes de fin d’année, offrez un petit bench à votre application préférée :
une soirée dédiée au Lyon JUG, mardi 21 décembre, animée par Claude Falguière.
C’est désormais une tradition gravée dans le marbre : préparez-vous avec l’interview teasing par les JDuchess.
Inscription et informations pratiques, as usual, sur la page officielle du Lyon JUG.
A mardi!
J’ai assisté ces derniers jours à la conférence Agile France 2010, 5ème édition de ce qui s’appelait « XP days » ces dernières années. Je vous livre ici mon ressenti sur ces deux jours de conférence que je considère comme un retour sur la situation de l’agilité en 2009. Pour situer un peu le contexte, j’y ai assisté en tant que Scrum Master/Développeur mais aussi dans une perspective future de coaching/accompagnement vers l’agilité.
La première chose marquante pour moi : sur plus de 60 présentations … à priori une seule a pour sujet principal Scrum et elle est annotée ‘Débutant’ ! Je me pose donc la question du pourquoi : est-ce que Scrum est déjà en cours d’abandon (les problèmes de certification lui ont certes causé du tort mais tout de même !) ? Devenu trop ‘mainstream’ pour qu’on ait encore des choses à dire dessus ? … Si vous avez des éléments de réponse, je suis preneur !
De même, les sessions sur la « vente » de l’agilité ont été plutôt rares (2 seulement) : l’agilité rentre dans les mœurs et il est devenu moins nécessaire de convaincre ?
En revanche le Lean s’est taillé la part du lion dans la catégorie ‘les bases des méthodologies’ pour une petite dizaine de présentations, associé à la bonne dizaine de sessions sur la transition de l’organisation vers l’agilité. C’est, il me semble, un point important à retenir : l’agilité commence à dépasser le cadre de l’équipe de développement pour s’installer dans les DSI en premier lieu et s’immisce doucement vers l’organisation de l’entreprise toute entière. Cela se fait principalement sur le constat suivant : les développements deviennent performants avec Scrum mais l’entreprise n’arrive pas à digérer cette performance, le lead time global peut difficilement changer si l’organisation n’est pas adaptée.
XP aussi est beaucoup ressorti, j’interpréterais cela de différentes façons : en premier lieu, la conférence s’est appelée XP Days pendant 4 ans, même si elle n’était pas exclusivement destinée à XP. Et puis c’est tout de même sur ces pratiques (plus que sur toute autre méthodologie … tiens, un élément de réponse :-) ) que les principes de l’agilité dans le monde du développement logiciel DOIVENT se reposer. L’accent a été mis sur les tests automatisés (10% des sessions) avec notamment le TDD qui commence à percer tout doucement. Et bien que ces pratiques soient globalement comprises elles restent toujours très peu mises en place.
Le dernier point que j’ai pu ressentir, certainement le plus important (pour moi étant donné mon profil mais aussi pour la réussite sur le long terme de projets de développement), c’est l’accent mis sur l’équipe, ses interactions et l’amélioration de la communication, le tout à la limite du développement personnel. Mais aussi un retour qui émerge : l’agilité à plein régime c’est exténuant et tout le monde ne supporte pas la transparence et le courage requis ! Le tout couronné d’une keynote d’Esther Derby sur l’alchimie équipe/management où comment se faire confiance réciproquement.
Ce fut une expérience instructive qui m’a permis de prendre un peu de recul et d’entrevoir de nombreux pans de l’agilité, et tout cela dans un environnement propice aux échanges dans un coin de verdure en bordure du bois de Vincennes. Un grand merci aux organisateurs !
Je continue mon tutorial sur soapUI. Voyons cette fois-ci comment utiliser soapUI pour réaliser des tests de charge.
Il faut ajouter un nouveau test de charge sur le TestCase voulu.
Note: il faut savoir que le test de charge va lancer tous les tests en parallèle, donc il ne faut pas qu’il y a de dépendance entre les services du TestCase, car ceci pourrait fausser vos résultats.
Une fenêtre s’ouvre, il est possible de choisir la stratégie de test et de la configurer.
A savoir : la durée du test, le nombre de threads à utiliser, le délai (aléatoire ou non) entre chaque nouvelle requête, etc.
Sur cette image on peut se rendre compte qu’un service qui renvoie une stacktrace d’exception est couteuse en temps et en données.
Le tableau de résultat affiche : le temps de réponse min max moyen, le nombre de requêtes totales lancées lors du test, le total de données transférées, le nombre d’erreur.
De plus, la console de log en dessous permet d’avoir des détails sur les tests déroulés, comme l’heure de début et de fin du test, les éventuelles erreurs, etc …
Suite de mon tutorial sur soapUI, voyons cette fois-ci comment pré-remplir certains champs d’une requête. Par exemple, un login et un password nécessaire pour se connecter.
Si vous avez une série de requêtes dans votre Test case, il est préférable de créer un script qui se chargera de vous pré-remplir ces champs plutôt que de le faire à la main 
Il faut créer un nouveau « step » nommé ‘Groovy Script’.
Voici un exemple de code qui pré-rempli les champs ‘login’ et ‘password’. Ces valeurs doivent être déclarées et initialisées dans l’onglet « Custom Properties » du projet (il s’affiche en cliquant sur le nom du projet).
Entrez ensuite le code du script :
Un petit Copier-(Réfléchir*)-Coller du code suivant simplifiera le travail ! (* © F.D.)
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
//variables definitions
def login = '${#Project#login}'
def password = '${#Project#password}'
//Retrieves all TestSteps of the current testCase
log.info("* " + testRunner.testCase.name )
def testStepList = testRunner.testCase.getTestStepList()
testStepList.each{currentTestStep->
if (currentTestStep.name != "Inits fields") { //ici liste des steps que le script ne doit pas modifier
log.info(" \\-- " + currentTestStep.name )
def holder = groovyUtils.getXmlHolder( currentTestStep.name+"#Request" )
log.info(" " + 'holder' )
holder.namespaces["ns"] = "http://schemas.xmlsoap.org/soap/envelope/"
//Inits values of the current testStep
log.info(" " + 'login' )
holder.setNodeValue("//ns:Body/*/login", login)
log.info(" " + 'password' )
holder.setNodeValue("//ns:Body/*/password", password)
//Updates the change
holder.updateProperty()
}
}
'Script OK'
Voici la requête une fois le script exécuté :
Note : pour éviter de faire un copier-coller du code à chaque Test case, il est possible de cloner ce « step » et le déplacer dans un autre Test case 
Dans un précédent article, je vous ai montré comment tester unitairement un Web Service. Cette fois-ci, nous allons aller un peu plus loin en testant l’enchainement de plusieurs Web Services.
Comme nous l’avons vu chacun de nos tests unitaires se trouve dans un arbre. Il est alors possible de lancer l’ensemble des tests de la suite, ou toutes les étapes d’un scénario, simplement en double cliquant sur le nœud correspondant de l’arbre. (Nœuds : TestSuite ou TestCase)
Une fenêtre s’ouvre et permet de voir les résultats
![clip_image002[10]](http://blog.objetdirect.com/wordpress/wp-content/uploads/2009/12/clip_image00210.gif)
A peine plus compliqué, il est aussi possible de récupérer une valeur dans une réponse et de l’injecter dans le test suivant.
Exemple d’utilisation : Dans nos jeux de tests, on veut réaliser l’enchainement suivant :
sachant que ce dernier service prend en paramètre un « request number » qui est renvoyé dans la réponse du « createOrder ».
Pour récupérer cette valeur et remplir notre requête « cancelRequestNumber », on utilise la fonctionnalité offerte par soapUI : le « Property Transfer ».
La valeur à récupérer (la « Source ») :
Le champ à remplacer (la « Target ») :
On ajoute un « step » ‘Property Transfer’ à notre Test Case « PropTransfer » :
On donne un nom au remplacement automatique qui sera effectué, à chaque exécution des tests :
On configure les chemins vers les champs qui nous intéressent :
Les chemins représentent les nœuds XML, de la requête et de la réponse SOAP, à parcourir pour atteindre les champs voulus
On place maintenant le « step » ‘Property Transfer’ entre les 2 tests (createOrder et cancelRequestNumber), de façon à obtenir un enchainement logique dans notre TestCase ‘PropTransfer’ :
On peut maintenant dérouler l’ensemble du Test Case
La forge logicielle de Xerox s’offre une version 4.0 née sous le signe de l’ouverture
Pour rappel, Codendi est une plate-forme collaborative de gestion de projet développée par Xerox, et permet de rassembler divers outils : gestion de code source, suivi de projet, gestion de documents, et d’autres outils de communication et de collaboration (forums, wikis, listes de diffusion, suivis de bugs).
www.codendi.org
Cette nouvelle version majeure s’accompagne d’un changement de philosophie dans le mode de distribution : le code source est désormais disponible au public, et téléchargeable gratuitement sur le tout récent site communautaire de Codendi, sous forme d’une image ISO. Cet outil sous licence GPL était auparavant distribué uniquement aux entreprises sous forme d’un service payant, comprenant support technique et mises-à-jour.
Il y aura désormais deux versions : une version communautaire gratuite « Codendi Labs », et une version « Pro », plus stable, distribuée aux clients. Codendi renforce ainsi sa position sur le marché open-source, quelques mois après avoir gagné le Lutèce d’Or dans la catégorie « Meilleur projet libre réalisé par un Grand Groupe ».
Plus techniquement, cette nouvelle version offre notamment les fonctionnalités suivantes :
Codendi est aussi partenaire du projet français COCLICO aux côtés de Bull, Orange Labs, Thales et l’INRIA, dont l’objectif est d’améliorer l’inter-opérabilité entre forges. Objet Direct contribuera également à ce projet en proposant notamment une application RIA pour le suivi de projet SCRUM.
Site communautaire de Codendi : http://www.codendi.org
Site professionnel de Codendi : http://www.codendi.com
Hudson, plate-forme d’intégration continue : http://hudson.dev.java.net
Derniers commentaires