juin 2007Monthly :

J'ai téléchargé la dernière version de NUnit 2.4 et je suis content des améliorations apportées à l'API. Le nouveau modèle d'assertion basé sur les contraintes rend les tests plus expressifs. Je n'écrirai plus les assertions du type: Assert.AreEqual(myString, "Hello"); mais plutôt: Assert.That(myString, Is.Equal("Hello")); ou mieux encore si ma classe de test hérite de AssertionHelper, je pourrai écrire Expect(myString, EqualTo("Hello")); Il me semble que cette syntaxe est plus lisible

Jimmy Bogard a un excellent message sur la classification des tests:

• Les tests unitaires vérifient le bon fonctionnement d'une méthode/fonction en isolation du reste du système. Ils doivent s'exécuter rapidement et n'avoir qu'une cause d'échec. Pour ce genre de tests on évite d'impliquer une base de données, un service web ou tout autre système externe.
• Les tests d'intégration vérifient le bon fonctionnement d'un système lorsqu'il est intégré avec les systèmes externes tels qu'une base de données par exemple. En général, ces tests vérifient que les données sont bien mises à jours dans la base de données ou qu'un courriel a bien été envoyé.
• Les tests fonctionnels vérifient le bon fonctionnement de l'application dans son ensemble du point de vue de l'usager.

À lire également le message de Jeffrey Palermo sur le sujet

J'ai visioné une présentation de Dan Ver Johnsson sur les Domain Logical Value Objects. C'est une présentation sur la manière d'introduire le Domain Driven Design dans du code patrimonial. En gros, le présentateur propose de commencer à rendre explicite les valeurs significatives pour le domaine en question: numéro de téléphone, taux de change, etc. De cette manière on peut rapidement bénéficier des améliorations suivantes:

1. Clareté des API de Service
2. Validation et gestion d'erreurs proches des données
3. Simplification du code de la logique de métier
4. Tests

Même si je suis d'accord avec les points présentés, je regrette toutefois que le présentateur aie ressenti le besoin de fournir un autre acronyme/terme technique: Domain Logical Value Object. Il me semble que tout ce dont il a parlé c'est des Value Object tels que présentés par Eric Evans dans son livre sur le DDD. Par ailleurs, à un moment donné il propose un exercice pour trouver les situations où l'application du DDD est opportune. Selon moi, la réponse est que cela dépend toujours du contexte dans lequel ces projets sont entrepris. On ne peut répondre juste en se basant sur l'énoncé du domaine. Il faut impliquer les experts afin de connaître où ils en tirent le plus de valeur.

Dernièrement, je donnais un cours sur le Domain Driven Design. Pour les exercices pratiques j'ai utilisé GreenPepper afin de pouvoir spécifier les fonctionnalités à accomplir sans pour autant imposer un design aux participants. Je dois avouer que je suis un peu perplexe quant au résultat de cette expérience. Les participants ont eu l'air de s'intéresser plus au produit qu'aux techniques présentées dans le cours afin de mieux cerner le domaine. Sans compter que l'apprentissage de l'outil peut constituer une barrière importante à la bonne conduite de l'exercice. Pourtant une approche basée sur des tests unitaires fournis ne me semble pas idéale car le design serait alors imposé. Les spécifications exécutables, par contre, se situent plus au niveau du modèle et du langage et de ce fait me paraissent encore plus appropriées...