Holà !
Voici le second billet d'une série de trois, entièrement dédiée aux TechEd 2007 de Barcelone.
Au programme et en images : la mise en oeuvre de Team System chez Microsoft pour le produit Visual Studio 2008, des techniques de tests unitaires, et construire sa propre Software Factory.
Bonne lecture,
Messaoud.
Customising Team Server Foundation for Application Lifecycle Management, Kevin KELLY
Connaissez-vous l'histoire de Visual Studio 2008 ?
Savez-vous que Team System a été utilisé pour sortir la CTP de Visual Studio 2008 ?
Vous voulez savoir comment Team System a été utilisé ?
Alors lisez ce qui suit...
Kevin KELLY est Senior Program Manager de Team System chez Microsoft. Et bien ce cher Monsieur, dont l'éloquence n'a d'égal que la richesse de son expérience, nous a donné une session courte mais passionnante sur : comment Team System a été personnalisé et étendu pour la CTP de VS2008 (" ORCAS "), démos à l'appui.
" Ni agiles, ni CMMi, chez MS nous faisons à notre manière " nous indique-t-il avant de présenter les personnalisations du Team Foundation Server pour le projet ORCAS.
Nous avons donc eu droit à :
Deux rapports personnalisés, dont
l'Exit Criteria qui liste l'état général des équipes projet ORCAS (en vertical sur le rapport), par critères (en horizontal). Cela permet de savoir si on peut ou pas sortir la CTP, puis précisément quelle équipe rencontre un problème, si ce problème est bloquant ou pas, et son critères ?
Que retenir de cette session ?
D'une part, que Microsoft utilise Team System. En vrai, et sur des projets conséquents, comme Soma l'avait indiqué dans la session de lancement des TechEd. Là, on le voit pour de vrai.
Et d'autre part, que Team System ne demande qu'à être adapté à un projet, exactement comme l'a fait Microsoft pour ORCAS CTP. Disons qu'il faut vraiment avoir une chance inouïe pour arriver à travailler correctement sur un vrai projet avec un TFS tel qu'installé par défaut (Next -> Next -> Next).
Qu'on se le dise : la personnalisation de TFS participe beaucoup de son adoption et de son succès, personnalisation que l'on pratique / a pratiqué chez tous nos clients Team System à OCTO.
Nécessaire, la personnalisation de TFS ne coûte pas très cher et rapporte gros,... alors à qui le tour ?
Unit testing tips & techniques with VS2008 and the .NET framework, R. OSHEROVE
Roy OSHEROVE est un type épatant !
Réunissez 300 fondus d'un sujet donné.
Prenez un talentueux speaker, et pertinent sur ce même sujet.
Mettez l'un en face de l'autre pendant 1 heure 15, et vous obtenez une " Interactive Session " du TechEd, un terrain dangereux sur lequel Roy s'est aventuré... et illustré avec brio !
Laissez-moi vous expliquer pourquoi.
L'un des talents de Roy, Agile Development and Team System Group leader chez SELA, ce sont les tests unitaires. A ce propos, il a écrit le framework MbUnit et est en train d'écrire un livre intitulé The Art of Unit Testing, On peut aussi le suivre régulièrement à travers son blog : www.ISerializable.com.
Roy commence la session en demandant au public : " Sur quels sujets voulez-vous échanger ? ". Il slide la liste des sujets qui fusent, puis lance un drolissime vote à mains levées pour prioriser les sujets.
En vrac, les sujets qui intéressaient le public...
Et pour savoir de quoi on va parler... on vote à main levée !
Voici un résumé des messages importants de cette session.
Sujet n°1: UI Testing
Au sujet des tests d'interface utilisateurs, Roy attaque fort en clamant : " Stop doing it ! It's timewaster ! " : trop longs à faire, in-maintenables car l'UI change trop souvent, et apportant peu de valeur, ...
A la place, il propose de coder en couches en MVC, où l'UI est clairement séparée de la logique métier.
Que dire de mieux ?
Pas grand-chose si ce n'est que des outils 100% .NET tels que Fitnesse ou GreenPepper tirent parti de ce type de design, et permettent avantageusement de se produire des tests de recette automatisés (ou encore : " spécifications exécutables ") plutôt que sur les tests d'UI.
Sujet n°2: DAL testing
Roy explique que tester la DAL sans base de donnée produit des tests creux, sans consistance. Plus encore : l'adhérence entre les deux est telle qu'il considère que c'est une et une seule couche. C'est un point de vue tranché, mais qui se tient !
Il parle aussi de SqlUnit, l'un des rares framework open source SQL, qui n'est pas utilisable en l'état...
Enfin, le plus important, il insiste sur le fait que tester la DAL ne doit pas créer de dépendance entre les tests, ni présupposer d'un ordre d'exécution. Ils sont isolés.
Pour cela, il présente l'utilisation de transactions dans un TU, dont le TearDown annule toutes les modifications effectuées par les méthodes d'une classe de TU. Il conseille même d'en faire une classe mère pour d'autres TU. Ce pattern fonctionne avec ActiveRecord, et NHibernate.
C'est propre.
Pour les intéressés, je précise que le livre Test Driven Development in .NET détaille ce pattern.
Sujet n°3 : les Mock Objects
Roy explique les Mock Objects : ce sont des classes qui simulent le comportement d'autres classes. Ces " simulateurs " sont principalement écrits pour les TU. Il illustre cela en implémentant une interface ILogger, un vrai logger, et un mock ‘FakeLogger'. Ca permet par exemple de tester unitairement une classe invoquant un simulateur de logger, sans craindre de dysfonctionnement de la part du logger (simulé).
Notons que cette implémentation qui passe par une interface, et dont la dépendance est 'par le constructeur', correspond à un choix de design. Il en existe d'autres.
Au passage, Roy dévoile sa règle de nommage de TU. Ses méthodes de TU comportent toujours 3 parties : le nom de la méthode à tester, le scénario, et le comportement attendu. Des exemples ?
" Sum_NegativeNumberAs1stParam_ExceptionThrow () " ou " Sum_simpleValues_Calculated () " (et surtout pas " PersonLogicTest1 ", " PersonLogicTest2 ", " PersonLogicTest3 "... !).
Roy souligne qu'il est inutile de préfixer ou de suffixer par ‘Test' puisque c'est redondant avec le custom attribute [Test] apposé sur la méthode ! Le nommage est important parce que dans les outils qui exécutent les méthodes de TU, on ne voit jamais les commentaires des méthodes, ni leurs corps, mais juste leurs noms...
Sujet n °4: NUnit versus MbUnit versus Team Test
Roy en vient finalement à positionner les principaux framework de TU. Pas facile quand on est l'auteur de l'un d'entre eux, que l'on est dans une conférence MS (qui a son propre framework de TU : " Team Test "), et de surcroît devant 300 personnes... :-) !
Après avoir fustigé Team Test en 2005, Roy reconnaît que la version 2008 est maintenant suffisamment stable et riche pour pouvoir être utilisée... bien que selon Roy il souffre encore d'un manque d'extensibilité.
NUnit est le standard de fait. Très simple et extensible, il le recommande pour débuter. Après, pour des fonctionnalités avancées et plus riches, on peut passer très simplement à MbUnit.
xUnit est encore plus simple que NUnit, mais les deux ne sont pas compatibles...
Enfin, il considère que le projet csUnit est mort et ne le conseille plus.
Roy m'a épaté à la fois sur le fond et sur la forme.
Ses points de vue sont tranchés mais pertinents. Il sait étayer ses explications d'exemples concrets de code, qui sont le fruit de son expérience. Ses messages font écho à nos convictions autour des tests, et à notre vision de l'architecte pragmatique chez OCTO. Bref, on adhère...
Ses points de vue sont aussi énoncés avec une audace cocasse mêlée à une certaine courtoise... Et puis, franchement, se quitter en chansons (" Le premier test unitaire est le plus dur... " et une version customisée de " Hey Jude ", vidéo de 30 Mo : btn droit : enregistrer sous...) où il s'accompagne à la guitare, faut oser non ?
Bref, si un jour vous avez l'occasion de voir Roy en session : courez-y ! Y'a à apprendre, à pratiquer... et à se marrer ! ! :-)
Build your own software factory, Don Smith - Denis Doomen - Olaf Conijn
Quelle étraaaange session que celle-là !
Animée par 3 experts des Software Factories (SF), dont l'excellent Don Smith, Product Planner dans l'équipe Patterns & Practices chez MS, cette session visait à promouvoir les SF, tout en nous éclairant sur les conditions de leurs succès.
Au final, de nombreuses pépites de conseils mettant en lumière des conditions et motivations " précises " de la mise en oeuvre des SF.
Retour sur ces conditions et motivations " précises " avec un résumé des grands messages de la session...
On peut consacrer un livre entier à définir les SF... Disons simplement que pour MS, une SF ce sont des patterns, modèles et processus de développement pour automatiser la construction de produits logiciels.
Concrètement, une SF se matérialise par quoi ? Essentiellement par de l'outillage spécifique pour générer du code. Des exemples d'outillages disponibles ?
L'Extensibility SDK de Visual Studio qui permet de fournir des instances personnalisées de Visual Studio aux développeurs. Un cas d'usage possible ? Générer le squelette d'une solution multicouches standard pour Visual Studio en 5 clics : UI, BLL, DAL, Core Domain, UT, SQL par exemple.
Voici un exemple de squelette de solution/projets WCF généré :
MS propose aussi les DSL Tools, pour générer le code correspondant à un modèle métier de conception, dans un style qui n'a de commun avec UML que sa fausse ressemblance graphique...
Une SF est toujours spécifique :
Une démo a été jouée sur une application de gestion de classe d'école, par exemple.
On en déduit l'anti pattern de SF suivant : vouloir se construire une SF multi technologies ou multi métiers...
Les 3 experts poursuivent et nous indiquent qu'une SF est envisageable si l'on factorise des produits existants, c'est-à-dire qui ont la chance d'être :
univoques ;
stables car éprouvés avec le temps (" durcis ") aussi bien techniquement que fonctionnellement ;
ancrés dans le réel avec des cas de test précis que l'on peut extraire des produits existants.
D'où l'anti pattern de SF : oubliez l'idée de construire votre SF " from scratch "...
Une SF coûte de 2 à 3 fois plus qu'un de ses produits. Son retour sur investissement devient intéressant à partir de 5 produits. En deçà, elle ne sera peut-être pas utile.
Anti pattern de SF : se faire sa SF pour 1 ou 2 applications...
Le processus de construction et d'évolution d'une SF est un processus foncièrement itératif. Le terme agile a été employé. Il convient de commencer petit, et de l'enrichir progressivement (" Start small and go big "), en tenant compte du feedback de ses utilisateurs pour ses évolutions.
En images et en détail, voici ce que cela donne :
- "Small to big" :
Le processus itératif de construction d'une SF :
- d'abord pour amorcer la SF :
Anti pattern de SF : au début de sa construction, il ne faut pas cibler une SF très très prometteuse, ou autrement appelée : une " usine à gaz ".
Derrière ses airs de session faussement naïve, cette session a présenté les principaux écueils des SF, tout en livrant quelques précieuses clés pour décider ou pas de les utiliser. Quelques derniers conseils avisés pour la route ?
Alors, cher lecteur, prêt pour y aller ?
Dans le dernier billet de cette série dédiée aux TechEd, il sera très probablement question de Team Build 2008, d'amélioration de performances avec Visual Studio, et probablement de la Web Client Software Factory.
Surtout, je pense que je vous présenterai ce que je considère être la meilleure session des TechEd, voire l'une des meilleures sessions qu'il m'ait été donné de voir. Je veux bien entendu parler de l'intervention de Pat HELLAND.
More than ever, stay tuned...
-- Messaoud OUBECHOU, meo@octo.com
Architecte Senior, coresponsable du Centre de Compétences .NET
OCTO Technology
)
