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.
Alors que cette approche permet assurément de tester plus facilement cette méthode, le réusinage de UserFacade en vue d’employer le modèle Repository facilite aussi les modifications concernant le mode et l’emplacement de stockage de vos données lorsque vous exécutez l’application en production.
Supposons que vous souhaitiez convertir votre magasin de données d’une base de données en service Web.
La seule chose à faire est d’écrire une implémentation de service Web de IUserRepository et de la passer à l’objet UserFacade. C’est aussi simple que cela ! Sans modifier le code dans UserFacade, vous effectuez les enregistrements et extractions au niveau d’un service.
Le recours à une implémentation de substitution de Repository est également utile pour gérer les dépendances dans votre calendrier de projet. Si votre équipe travaille sur un système de grande envergure, les personnes qui écrivent le code pour l’accès aux données peuvent suivre un calendrier distinct d’autres membres de l’équipe. La description du contrat concernant ce qu’il va se passer dans votre application via une interface est généralement nettement plus rapide que d’attendre que cet aspect soit réellement écrit.
En utilisant des interfaces et des Repository, vous pouvez décrire rapidement les interfaces, puis écrire les implémentations de substitution qui vous donnent suffisamment de fonctionnalité afin d’écrire le reste de l’application.
Maintenant que la base de données est éliminée du test UsernameExists(), vous allez peut-être vous demander comment tester la logique d’accès aux données. C’est simple : écrivez les tests unitaires sur l’implémentation de base de données de IUserRepository. Cette approche aboutit en réalité à un test amélioré et plus propre, car vous testez la logique d’accès aux données directement, au lieu de le faire via une autre fonctionnalité. Malheureusement, lorsque vous écrivez ces tests, vous devez toujours vous préoccuper de la logique pour configurer et initialiser la base de données avec des données de test appropriées. Ce point est relativement fastidieux mais, au moins, c’est le seul aspect dont vous devez vous préoccuper pour les tests Repository au lieu que cela devienne un souci pour chaque test qui utilise un Repository.
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
