J’ai une petite question pour ceux qui utiliseraient NHibernate et un framework de test unitaire.
Je suis en train de travailler sur un projet utilisant ASP.Net MVC et pour la partie accès aux données j’utilise Fluent NHibernate.
Au niveau de l’architecture j’utilise le repository pattern pour accéder aux données depuis mes controllers. Donc, mes controllers prennent en paramètre du constructeur un IRepostory et les constructeurs de mes repository prennent une ISession. J’utilise un framework d’IoC (StructureMap en l’occurence) pour injecter les dépendances.
J’ai fait un premier petit test et tout fonctionne parfaitement bien.
Là où j’ai un soucis c’est pour les tests unitaires au niveau du repository. Comme mes repository demandent une implémentation d’une ISession, je devrais en avoir un pour les tests unitaires. Le problème c’est que cette ISession est un gros machin compliqué à “Mocker”. Du coup je me retrouve un peu coincé. J’ai fait quelques recherches sur le net et beaucoup proposent d’utiliser une petite base de donnée, genre SQLite pour les tests unitaires des repository, mais je trouve ça pas très propre et ça risque de ralentir pas mal l’exécution des tests.
Du coup, est-ce que quelqu’un a déjà eu affaire à ce genre de problèmes? Existe-t-il une solution que j’aurais oublié d’envisager?
soit tu mockes ta session, et tu dois couvrir tous les cas d’utilisation de ton test (recherches, accès par id, transaction, etc.) ;
soit tu laisses la véritable session et tu fais du SQLite…
La première solution me semble tout à fait faisable dans le cas d’un test pour un cas précis de ton repository. La seconde est plus souple, mais teste aussi ta BD, alors que la première s’intéresse uniquement au repository.
Effectivement, c’est ce que je sous-entendais par utilser SQLite, mais reste que ce n’est pas aussi rapide que d’utiliser un Mock et ça risque de ralentir sensiblement l’exécution de l’entier de mes tests. Ca a l’autre désavantage de ne pas tester que ce que je souhaite tester (mon repository) mais de tester en plus la base de donnée, ce qui n’est pas top.
Ceci dit, je crois que c’est quand même le plus simple et je vais probablement faire ça. J’ai trouvé sur un site (Stackoverflow je crois) un commentaire qui disait qu’une solution pour les soucis de rapidité serait de définir ces tests avec une catégorie spéciale et de ne les lancer que s’il y a eu modification de la structure des données ou d’un repository. Je trouve que ce n’est pas une si mauvaise idée puisque de toute manière les repository changent relativement peu souvent et sont bien séparés entre eux.