SharePoint 2007 : Un peu de qualité dans ce monde de brutes

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 :

  1. Quel est l’apport de TypeMock dans la réalisation de test unitaires appliqué à SharePoint ?
  2. 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.

TypeMock

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.

coach sharepoint

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.

patterns and practices

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”…

WTF Minutes

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

Industrialisation des Développements SharePoint

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/>

Publié mardi 9 juin 2009 13:10 par phil
Classé sous , , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

About phil

Philippe Sentenac est Consultant SharePoint à Wygwam en région Parisienne. Il intervient essentiellement sur des missions liées à SharePoint (2007 et 2010 ) mais aussi autour du Web 2.0. Plus généralement, il s'intéresse à l'ASP.Net (MVC) , à Silverlight, et à tout ce qui est orienté Web en rapport avec les nouvelles technologies, qu'il pratique depuis 2006. Féru de développement, il est passionné par les problématiques de méthodologies et d'industrialisation du développement.

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01