En suivant ces sept conseils, vous serez prêt à faire face à un sinistre, voire éviterez le problème des tests d’intégration de bout en bout avec le modèle de développement (Repository pattern).
De nombreux développeurs doivent écrire des tests unitaires dans le cadre d’une généralisation de la conception et du développement axés sur les tests.
Un moyen remarquable de séparer la méthode UsernameExists() du code d’accès à la base de données consiste à introduire une interface et à appliquer le modèle Repository. Le rôle de ce modèle est d’isoler la fonctionnalité de modèle de domaine (objet métier) de la fonctionnalité d’accès aux données. Un modèle Repository fournit une interface simple pour enregistrer et récupérer les objets métier, et pour encapsuler les détails d’implémentation du travail. Voici une conception d’interface Repository pour l’objet User.
Dans une application à n niveaux qui utilise le modèle de domaine et enregistre sur la base de données, il vous faut un moyen de distinguer un objet d’un autre. C’est ce que l’on appelle l’identité d’un objet. La valeur d’identité pour un objet est généralement identique à la colonne de clé primaire pour la table qui stocke les données.
Lorsque vous créez une application à n niveaux, essayez de faire en sorte que tous les objets utilisent la même propriété pour décrire leur identité. Cette approche permet d’avoir un modèle d’objet propre et cohérent. Vous pouvez appliquer cette cohérence en créant une interface qui permet d’accéder à la propriété d’identité pour vos objets. Dans l’exemple d’application de cet article, il s’agit de l’interface IInt32Id, laquelle définit une seule propriété nommée Id et désigne un entier.
Tous les objets de modèle de domaine implémentent IInt32Id, ce qui contribue à conserver une conception propre et cohérente pour vos référentiels. Afin de bénéficier d’une bonne réutilisation, une interface IRepository<T> définit les opérations CRUD pour tous les objets métier dans l’application. Si un objet métier a besoin de méthodes Repository absentes de IRepository<T>, vous pouvez créer une interface spécifique à l’objet et y ajouter la méthode. Dans le cas de la fonctionnalité UsernameExists(), une interface IUserRepository implémente IRepository<User> et possède une méthode GetByUserName().
Maintenant que vous avez défini les interfaces Repository, vous pouvez réusiner UserFacade afin d’employer cette interface pour l’accès aux données au lieu de l’objet UserDataAccessObject. Même si l’exemple de code ci-dessus est très similaire au code original, l’objet UserFacade ne se préoccupe plus de l’implémentation d’accès aux données utilisée. Tant que vous fournissez une instance de IUserRepository sur le constructeur, la méthode UsernameExists() a tout le nécessaire pour effectuer son travail. En masquant cette logique derrière une interface et en la passant au constructeur, vous avez l’opportunité d’utiliser une implémentation de substitution de IUserRepository.
Dans les tests unitaires, une simulation ou substitution (mock) est un objet qui implémente une interface et fournit une version simplifiée au lieu de l’implémentation complète que vous allez employer en production. Dans ce cas, vous pouvez passer un objet de substitution qui implémente IUserRepository et fournit la fonctionnalité de base de données en mémoire au lieu de faire appel à la base de données réelle.
Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.
