Scrum.org la révolution des développeurs

batswirl — Mon, 26 Apr 2010 14:44:00 GMT

Si vous ne connaissez pas encore Scrum.org et que vous travaillez actuellement dans un contexte agile, je vous conseille fortement de faire une petite visite sur le site.

Il s'agit d'une nouvelle initiative visant à promouvoir Scrum et l'agilité et à former les acteurs d'un projet à ces nouveaux contextes.

Ken Schwaber, le papa de Scrum, est à l'origine du projet et a établi un programme spécifique pour les développeurs. Le programme comble ainsi un manque terrible dans bon nombres de cursus agiles : la formation des développeurs.
L'objectif est ici de fournir la connaissance des outils et des pratiques qui permettront à un développeur de répondre aux différentes contraintes des projets agiles :

réactivité
Développement empirique
gestion du changement
collaboration
...

A l'heure actuelle, deux cursus sont disponibles pour les deux plate-formes majeures de l'industrie .Net et Java.
A Pyxis technologies, nous comptons parmi nous les 2 seuls formateurs francophones (Eric Mignot et Ernst Perpignand) et j'aurais l'occasion de binômer avec eux sur ces formations et ainsi apporter mes connaissances et mon expérience sur Team System et Team Foundation Server.

Les dates :

du 7 au 11 juin à Montréal

du 21 au 25 juin à Paris

En espérant vous rencontrer devant un VS10 pour parler architecture agile, TDD, scripts de build…

Rhino Mock / MSTest : Isolation

batswirl — Sun, 07 Feb 2010 21:23:00 GMT

Dans ce post, j’aimerais vous présenter diverses méthodes permettant d’effectuer des tests de comportements sur vos composants. On ne teste pas le contexte, les données retournées mais bien le comportement de la routine avec l’appelant et les dépendances.

Contexte

On souhaite tester une méthode d’un dépôt(notion de repository en DDD). La routine en question est un service permettant d’envoyer des entités (Demande) à un service Web pour centraliser ces demandes. Les différentes actions effectuées sont les suivantes :

L’appelant appelle la méthode EnvoyerTout prenant en paramètre une liste de Demande.

Le dépôt reçoit la liste et vérifie les informations de synchronisation dans une base de données locale.

Le dépôt envoie la liste des demandes et les informations de synchronisation au service.

Le service répond et fournit des informations permettant d’enregistrer en local que les demandes ont déjà été envoyé au serveur.

Afin de limiter le trafic réseau, on souhaite vérifier que les demandes réellement envoyées au serveur n’avait jamais été envoyées. Cette information est disponible dans la base de données de locale.

On souhaite isoler le comportement de cette routine car nous détectons rapidement les différentes dépendances :

Un service Web qui doit répondre aux différentes requêtes du proxy.

Une base de données contenant des informations de synchronisation.

Une utilisation d’une dépôt permettant de récupérer les informations de l’utilisateur.

Explication du test

Voici donc le test en question :

   1:          [TestMethod]

   2:          public void EnvoyerToutNAjouteQueLesDemandesJamaisSynchronisees()

   3:          {

   4:              utilisateurDepot = mockRepository.Stub<IUtilisateurDepot>();

   5:              demandeDeControleService = mockRepository.StrictMock<DemandeDeControleService>();

   6:              demandeDeControleServeurDepot = mockRepository.Stub<DemandeDeControleServeurDepot>(demandeDeControleService, utilisateurDepot);

   7:              Expect.Call(demandeDeControleServeurDepot.GetReplicaId()).Return(Guid.NewGuid());

   8:              demandeDeControleServeurDepot.MettreAJourTousLesWatermark(null, 0);

   9:              LastCall.IgnoreArguments();

10:

  11:              Expect.Call(demandeDeControleService.EnvoyerTout(null)).IgnoreArguments().Return(0).Repeat.Once();

  12:              mockRepository.ReplayAll();

13:

  14:              demandeDeControleServeurDepot.EnvoyerTout(CreerUneListeDeDemandes(5, 2));

15:

  16:              ServiceDomain.DemandeDeControle[] demandeDeControleEnvoyees =

  17:                  (ServiceDomain.DemandeDeControle[])demandeDeControleService.GetArgumentsForCallsMadeOn(x => x.EnvoyerTout(null)).First().First();

  18:              Assert.AreEqual(2, demandeDeControleEnvoyees.Length);

  19:          }

Pour décrire ce test commençons par le commencement d’un test à savoir son assertion :

Ligne 18 : Assert.AreEqual(2, demandeDeControleEnvoyees.Length); On vérifie ici que le nombre de demandes envoyés au serveur est bien égale à 2.

On pourrait donc traduire cette assertion de la sorte : Si l'application fournit une liste de 5 demandes au dépôt mais que seuls 2 demandes de cette liste doivent être envoyées au serveur, vérifie que le dépôt n'a envoyé que ces 2 éléments au service.

Pourquoi?

Ligne 14 : demandeDeControleServeurDepot.EnvoyerTout(CreerUneListeDeDemandes(5, 2)); C’est la routine que nous souhaitons tester. Dans le test, le paramètre (la liste de demandes suceptibles d’être envoyées) est fourni par une méthode du test CreerUneListeDeDemandes(5, 2) prenant en paramètre le nombre total de demande à créer et le nombre de demandes à synchroniser (et qui doivent donc réellement être envoyées au serveur).

Et la rapport avec l’assertion?

Ligne 16 et 17 : On récupère le premier paramètre du premier appel (il n’y en a qu’un) de l’exécution de la méthode EnvoyerTout d’un mock (demandeDeControleService) .C’est le cœur même du test et l’objet de l’assertion. Ces paramètres proviennet directement du mock, le service n’est jamais instancié.

Et comment c’est possible?

De la ligne 4 à la ligne 9 : on prépare l’exécution du test en isolant, à l’aide de diverses techniques et fonctionnalités de RhinoMock, les dépendances détectées.

Ligne 4 : on crée un stub du dépot utilisateur, aucun comportement ou données ne nous sont nécessaires. Nous avons juste besoin d’une instance de ce dépot pour l’instanciation ligne 6. Le fait de le “stuber” permet de ne pas exécuter le code de ce dépôt.

Ligne 5 : On crée un mock strict. Toutes les fonctionnalités du service seront recrées et tous les appels vers le service seront redirigés vers ce mock.

Ligne 6 à 12 : Création du mock partiel du composant testé. Toutes les routines réclamant un contexte (ligne 7 et 8, la récupération des informations de synchronisation nécessite une base de données locale) sont redirigés vers le mock. On peut configurer le résultat de l’exécution de la méthode du mock (ligne6 : demandeDeControleServeurDepot.GetReplicaId()).Return(Guid.NewGuid()) ) ou l’on peut déclarer d’ignorer l’appel et les paramètres (ligne 7).

Sur ce mock partiel, on appelle la méthode testée (ligne 11).

Tous les comportement d’isolation ne seront disponibles qu’après la ligne 12. Celle-ci permet d’informer RhinoMock des différentes instructions d’isolation.

Conclusion

Pas de base de données à construire et de données à générer. Pas de service sur un serveur de test. Mais le comportement attendu est vérifié et le sera même en cas de changement de source de données, de modification du contrat de service…

Cool non?

Batswirl : TDD

Scrum.org la révolution des développeurs

Rhino Mock / MSTest : Isolation

Contexte

Explication du test

Conclusion