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.
Même les équipes qui ne pratiquent pas stricto sensu les méthodologies agiles sont concernées. Le développement orienté tests (TDD ou Test-driven development) peut produire du code plus propre en exigeant des équipes de projet qu’elles écrivent d’abord des tests unitaires qui échouent, puis qu’elles programment juste ce qu’il faut de code pour une fonction nécessaire, qu’elles retestent, qu’elles réusinent le code et qu’elles répètent le cycle. Si vous n’avez pas encore écrit de code au moyen du développement TDD, le fait de partir de tests qui échouent peut sembler bancal. Mais c’est justement l’étape de réflexion supplémentaire à propos du résultat souhaité qui vous donne une compréhension plus claire du travail à accomplir.
Si vous écrivez une application à n niveaux (n tier) au moyen de Visual Studio et si vous souhaitez mettre en oeuvre le développement TDD, il n’est pas rare que vos tests unitaires pour la fonction métier effectuent des opérations de lecture et écriture sur une base de données. Pour que ces tests fonctionnent, il faut une base de données opérationnelle avec le schéma le plus à jour possible et les données associées.
Qu’en est-il si vous écrivez des tests unitaires pour une application orientée services et que votre code doit appeler un service WCF (Windows Communication Foundation) s’exécutant sur une autre machine ? Ou encore, que se passet- il en cas d’appels à un grand système ou un autre système back-end ? A ce stade, est-il même pratique d’écrire les tests d’intégration par rapport à ces systèmes ?
La solution à ce problème d’intégration de bout en bout consiste à commencer par utiliser le modèle Repository, afin de « simuler » votre base de données ou d’autres systèmes back-end et de découpler votre logique applicative de ces dépendances. Martin Fowler décrit le modèle Repository en déclarant qu’il « s’intercale entre les couches de domaine et de mappage de données au moyen d’une interface de type collection pour accéder aux objets du domaine » (« Pattern of Enterprise Application Architecture », Addison Wesley Professional, 2002).
Si votre niveau métier utilise vos modèles Repository comme interfaces, vous pouvez alors introduire facilement des versions de substitution utilisables pour les tests, puis introduire les versions de base de données au moment de l’exécution. Au final, vous disposez d’un moyen de tester votre fonctionnalité de niveau métier sans nécessiter une base de données opérationnelle ou un autre système back-end. A titre d’effet collatéral, la maintenance du code s’en trouvera facilitée, car vous aurez réduit le niveau de couplage dans votre application.
Le présent article explique comment exploiter le modèle Repository afin d’éliminer la dépendance à SQL Server pour vos tests unitaires et, ce faisant, comment améliorer la testabilité de votre application. Les fonctions de tests unitaires abordées ici sont toutes disponibles dans Visual Studio 2008 Professional Edition et dans toutes les éditions de Visual Studio 2008 Team. L’exemple d’application est écrit dans Visual Studio 2008 Team Suite et nécessite une instance de SQL Server ou SQL Express.
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.
