Afin de me remettre un peu en mode blogueur (cela faisait un petit moment que j’étais loin de ce blog), je me suis dis qu’il serait bien de clarifier un peu mes propos par rapport à mes derniers posts.
En effet, depuis les posts : SharePoint 2007 : Utilisation du pattern MVP et Tests Unitaires avec TypeMock et SharePoint 2007 : Accès aux données et Test Unitaires, j’ai eu de nombreux retours via collègues et blog me demandant de clarifier deux points importants :
- Quel est l’apport de TypeMock dans la réalisation de test unitaires appliqué à SharePoint ?
- Quel intérêt de faire des applications utilisant les patterns MVP, Test Unitaires, Test Web, voire de l’industrialisation des développements SharePoint ?
Concernant le premier point, sur l’intérêt de TypeMock, il faut toute d'abord se rendre compte que toute application SharePoint a une facheuse tendance à avoir une dépendance sur l’environnement SharePoint (J’enfonce des portes ouvertes, j’en ai bien conscience mais suivez ma logique). En effet, quand je développe une webpart, mon accès aux donnée va exécuter des requêtes CAML sur un SPWeb, un SPSite, etc..
Dans nos développements, Ce lien à SharePoint à 3 inconvénients majeurs :
- Nécessité d’avoir un environnement SharePoint lors de l’exécution des test (unitaires/web/charges)
- Un ralentissement dans l’exécution des tests pendant la phase d’accès aux données
- Nous souhaitons tester uniquement notre code et pas telle ou telle méthode de mon objet SharePoint déjà testé par Microsoft.
Idéalement, nous voudrions donc remplacer l’appel au modèle objet SharePoint par des “Fake”. Un objet “Fake” est un objet créé par le développeur dans le cadre d’un test unitaire qui va permettre de passer les paramètres souhaités dans le contexte du test donné tout en conservant le type de l’objet initial.
En clair, appliqué à SharePoint, si j’ai une webpart qui doit afficher le Titre du SPWeb courant dans un champ texte, j’accéderai par exemple à SPContext.Current.Web.Title. Dans ce cas, je voudrais avoir plusieurs tests unitaires qui vont vérifier les cas d’erreur (Titre vide, longueur de chaine excessivement longue, etc…).
Je voudrais donc avoir la possibilité de paramétrer mes tests unitaires en passant à la webpart quelque chose dans ce style :
1: SPWeb webWithTitleNullOrEmpty = new SPWeb(){ Title = String.Empty }; 2: SPWeb webWithTitleLong = new SPWeb(){ Title = “TrèsLongueChaineEtc…” }; 3:
4: // Test chacun des cas ....
Mon problème est que la manière d’obtenir un SPWeb diffère pour chacun de ces tests et m'oblige donc à avoir un site web différent pour chaque cas sur mon environnement :
1: using (SPSite site = new SPSite(“http://dev-sharepoint/collectiondesite”))
2: { 3: SPweb webWithTitleNullOrEmpty = site.OpenWeb(“WebWithTitleNull”);
4: // etc..
5: }
En effet, je n’ai pas de constructeur qui me permettrait d’initialiser ce genre d’objet dans le modèle objet SharePoint selon mes besoins, je suis obligé de me basé sur un environnement SharePoint réel. Je ne vous parle pas du temps nécessaire pour créer tout les variantes pour les test unitaires sur vos environnements, ce n’est tout simplement pas possible de fonctionner comme ça.
Ceux qui connaissent des Frameworks comme RhinoMock ou Mock, auront tendance à vouloir utiliser ces frameworks pour créer un “Fake” des objets SharePoint mais malheureusement, ces frameworks sont incapables de générer des “Fake” à partir de classes qui sont “Sealed” ou qui n’ont pas de constructeur public.
Hors l’API SharePoint utilise de façon intensive des classes “Sealed” et des classes avec des constructeurs “Internal” et à l’heure actuelle, TypeMock est le seul Framework de Mock qui permet de générer ces “Fake”.
1: // Création d'un fake SPContext
2:
3: SPContext context = Isolate.Fake.Instance<SPContext>(Members.ReturnRecursiveFakes);
4:
5: // Possibilité de paramètrer le fake pour qu'il retourne telle ou telle valeur...
6:
7: Isolate.WhenCalled(() => context.Current.Web.Title).WillReturn("Hello World");En résumé : Si vous souhaitez faire des tests unitaires appliqués à SharePoint et que vous souhaitez les exécuter rapidement et sans dépendance sur un environnement SharePoint, la seule solution à l’heure actuelle est TypeMock.
Concernant le deuxième point, sur l’intérêt des patterns MVP, Test Unitaires, Test Web, bref de la série de posts que j’ai faite depuis quelques mois…, mon point de vue est sans doute biaisé :)
Depuis plus de 2 ans de SharePoint, j’ai appris que réussir des projet SharePoint n’est pas forcément facile surtout quand il y a un pourcentage non négligeable de développement personnalisé dans le cadre du projet.
Ceci s’explique par de nombreuses raisons :
SharePoint nécessite de travailler dans un environnement virtualisé. La création de cet environnement prend du temps, en moyenne une journée par développeur. Souvent, les responsables de projets ne pensent pas à planifier ce temps là et dès le départ du projet on se retrouve rapidement avec une semaine de retard pour une petite équipe de 5 développeurs. Heureusement, il existe plusieurs moyens pour réduire ce délai (cf SharePoint 2007 : Automatiser la création de votre environnement SharePoint)
Les développeurs/architectes doivent non seulement assimiler deux Frameworks supplémentaires (WSS et MOSS) en plus du .NET et d’ASP.Net mais aussi connaîttrent parfaitement la partie administration afin de pouvoir différencier une demande de fonctionnalité Standard d’une demande de développement. Cette connaissance ne s’acquiert pas en un jour et encore moins sans accompagnement ou formation… Ne pas s’assurer que l’équipe est correctement formée a bien souvent mené de nombreux projets à la poubelle. C’est valable pour toutes les technologies ceci-dit,mais la particularité de SharePoint est qu’il demande plusieurs paires de bras pour bien assimiler le produit.
Selon mon expérience, une personne accompagnée ou formée sur WSS/MOSS est la plupart du temps 3 à 4 fois plus rapide qu’un débutant. Imaginez les impacts sur vos plannings de projet… C’est d’ailleurs pour cette raison que Microsoft et plusieurs autres entités (Combined Knowledge notamment) n’ont eu de cesse de crée du contenu de formation dans le but de faciliter la montée en compétences de vos équipes (cf SharePoint 2007 : Découvrir et se former à SharePoint)
Mais cette connaissance de SharePoint à d’autres implications. Il y a quelques spécificités SharePoint comme la génération de packages WSP, le déploiement, les bonnes pratiques concernant la libération de la mémoire (cf SharePoint 2007 : Dispose Patterns et l'outil SPDisposeCheck) qui misent bout à bout peuvent grandement influencer la bonne santé de votre projet. De plus, la plupart des guides de développement SharePoint restent assez basiques et n’utilisent pas ou très peu d’architectures connues et reconnues (3 couches, Patterns, etc…) et se reposent souvent sur ce qu’on appelle l’ASP.Net Spaghetti.
Heureusement depuis peu, une lumière apparaît au bout du tunnel, un exemple de bonnes pratiques de développement nous ait montré par l’équipe de Patterns & Practices (cf SharePoint 2007 : Patterns & Practices Guidance). Leur exemples de développement SharePoint nous montre qu’il est aussi possible dans SharePoint de “coder proprement” et même d’avoir des tests unitaires/web/charges.
Néanmoins, soyons honnêtes, autant le fait de dire “Coder proprement, c’est mieux” suffira la plupart du temps à convaincre un développeur de la validité d’une discussion sur tel ou tel bout de code autant un fonctionnel ou un décideur n’y verra pas ou peu d’intérêt. “Tant que ça marche, quel différence peut il y avoir”…
A mes yeux, baser les développements SharePoint sur l’utilisation de divers patterns ou tout simplement “bien coder” (cf : SharePoint 2007 : Utilisation du pattern MVP et Tests Unitaires avec TypeMock) va permettre une meilleure isolation entre chaque couches de vos développements. Cette isolation va potentiellement rendre le code plus lisible et entre autres choses permettre l’utilisation de test unitaires/charges/web. Un code plus lisible et mieux testé est souvent certes plus long à créé mais sur le long terme coutera moins d’argent et temps :
- Le code est plus simple à lire pour les nouveaux arrivant dans l’équipe = Moins de temps de perdu tout au long du projet lors des changements dans l’équipe.
- Le code est testé ce qui va réduire drastiquement le nombre de bugs = Moins de temps de perdu pendant la phase de développement, pendant la phase de recette et pendant la période de support à la fois pour le client et pour l’équipe de développement.
- L’application est plus facile à mettre à jour (il est plus facile de remplacer tout ou partie de l’application) = Moins de temps de perdu pendant la phase de développement et pendant la période de support à la fois pour le client et pour l’équipe de développement.
Pour finir, l’idée même de cette série sur l’industrialisation des développement SharePoint (avec Team System) est de montrer qu’il est possible d’avoir pour vos projets SharePoint :
- un Gain de temps avant, pendant et après le projet
- une Aide à la gestion et au suivi de projet
- une Amélioration de la qualité
- et une Réduction des coûts
Voilà quelques liens pour vous donner quelques idées ce qu’il est possible de faire :
J’espère que c’est un peu plus clair maintenant :)
<Philippe/>
