Discussion :

[nico-pyright(c)]

je reprends l'idée d'un billet que j'ai publié récemment afin de receuillir vos expériences.

C'est toujours difficile de tester sa DAL, j'ai trouvé plusieurs méthodes :

Ajouter, supprimer manuellement les données qui ont pu être supprimées, ajoutées à chaque test. Cela nécessite d'exécuter du sql en vrac à chaque test et peut être un travail laborieux et décourager le développeur quand les données sont nombreuses.

Restaurer un dump de la base de données de test après chaque exécution du test. Cela est très problématique si la base de données est volumineuse.

Avoir un moyen de mettre une base de données de test dans un certain état à chaque début de test (Unit Testing the Data Access Layer, par Tim Stall, Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer, par Steven A. Smith). Cela nécessite un gros travail pour mettre sa base en état (construction de script sql pour vider la base, construire la structure, ajouter les données, etc ...) et un temps non négligeable d'exécution à chaque test. Cela peut aussi être gênant lorsqu'on travaille à plusieurs sur la même base de test.

Avoir une base de données de test et exécuter chaque opération CRUD dans une transaction qui sera ensuite annulée. Cela nécessite de rajouter du code spécifique dans nos tests pour créer et annuler la transaction.

Utiliser COM+ entreprise services (ou COM+ 1.5) et utiliser une classe de base pour ses tests qui encapsule la création et l'annulation de la transaction (Simplify Data Layer Unit Testing using Enterprise Services de Roy Osherove). Cela nécessite d'avoir un provider ADO.NET qui supporte les transactions distribuées, ce qui est quand même le cas de bon nombre d'entre eux et nécessite d'exécuter que des commandes sql qui peuvent être utilisées dans une transaction distribuée.

Des frameworks de test (MbUnit, XtUnit, NunitX) semblent utiliser des attributs à poser sur ses tests pour effectuer la restauration des données altérées)

Et vous, comment testez-vous vos DAL ?
Avez vous testé l'une de ces méthodes ? Quels sont vos retour d'expérience ?

[tyzef]

Tiens c'était justement la question de la réunion d'équipe aujourd'hui ... Ca tombe bien

[nico-pyright(c)]

et qu'avez vous répondu alors ?

[LooserBoy]

Et vous, comment testez-vous vos DAL ?
Avez vous testé l'une de ces méthodes ? Quels sont vos retour d'expérience ?

En ce qui me concerne, deux méthodes ont été utilisées:
- Restauration d'une base "propre" avant chaque test. Effectivement, cela est problématique avec une volumétrie importante. On avait limité le problème en ayant une base de test allégée en données (à 0% de matières grasses ).

- Mettre la base de test partagée par l'équipe dans un état prédéterminé par script SQL pour se simplifier la tâche. C'est la méthode utilisée dans ma mission actuelle. On se "télescope" énormément entre nous. Mais compte tenu de la volumétrie très importante, on a pas mieux à proposer pour le moment.

[Maximil ian]

J'ai expérimenté lors de récents projets une structure qui fonctionne pas mal :

Branchement de la DAL sur une base en mémoire (style SQLite) lorsqu'on est dans un contexte de tests.

Génération du schéma de base (ça se fait facilement avec un ORM comme NHibernate) et remplissage des données minimales à chaque lancement de testFixture.

Après chaque test, rollback des modifications faites par le test.

Au niveau perfs, la différence par rapport à un "vrai" SGBD sur le poste du développeur, et d'autant plus par rapport à une base mutualisée, est assez significative.

Toutefois le temps d'exécution de ce genre de test reste tout de même élevé pour un projet conséquent, c'est pourquoi je pense qu'il faut essayer de limiter au maximum les tests unitaires qui interagissent avec la base de données. C'est d'autant plus vrai dans un contexte d'intégration continue ou les tests sont joués très régulièrement.

[Plageman]

Pour ma part, avec une base Firebird:
- la dll de test unitaires utilise Firebird Embedded, ce qui évite d'avoir besoin de firebird sur le serveur ou le poste de test, ou de gérer des bases de test pour plusieurs développeurs
- pour chaque test le nécessitant, une copie de base vide de données (avec firebird c'est un fichier) est faite et un script d'insertion de données est exécuté.
Cela permet aussi d'avoir les scripts des données de tests dans subversion par exemple et voir l'historique des modifications.

Cette façon de faire ne ralentit pas de façon notable l'exécution des tests, mais nous n'avons pas une énorme base avec genre 400 tables, et le jeu de données inséré à chaque fois est celui minimum pour la réussite d'un petit ensemble de Tests.
D'un autre coté, un base de test pour les test unitaires ne devrait pas être volumineuse ? (on ne teste pas les performances.)

Edit :
ah, c'est exactement la solution déconseillée par Maximilian

[Maximil ian]

ah, c'est exactement la solution déconseillée par Maximilian

Heu, je ne la déconseille pas, c'est un mal nécessaire De toute façon, pour tester la DAL (ce qui est le sujet original du thread) on ne peut pas y couper.

Simplement un test unitaire qui n'a pas pour objet l'accès aux données lui-même devrait autant que faire se peut éviter toute dépendance à la couche d'accès aux données. Sinon il n'est plus vraiment unitaire, ça devient un test d'intégration.

Easy to Setup

How easily can I set up an environment to run the tests? If the answer is "not very," I might never get the tests running. As much as possible, decouple unit tests from external dependencies like databases and web services by using mocks or stubs. When you do test against an external dependency, the dependency better be setup correctly by the automated build.

http://codebetter.com/blogs/jeremy.m...20/129552.aspx

[cf1020]

Bonjour,
Moi personnellement je programme depuis 1981 et avec les années, j'ai peaufiné une technique qui consiste a exéctuer une routine de testes à chaque lancement de l'application qui va mettoyer toutes les tables de la BD qui subissent des mouvements (insertion, update et delete), et ca fonctionne très très bien depuis une dizaine d'années maintenant.

[Patriarch24]

En Java il existe une api, dbunit, qui sert justement à réaliser des tests unitaires et d'intégration pour les couches d'accès aux données. Peut-être en existe-t-il un équivalent pour .Net ?

[ktechlab]

Dans notre entreprise nous utlisons NDbUnit pour cela.

Baké Jc. BAKENEGHE
Sofware Coordinator
http://koossery-tech.fr

[nico-pyright(c)]

Utiliser COM+ entreprise services (ou COM+ 1.5) et utiliser une classe de base pour ses tests qui encapsule la création et l'annulation de la transaction (Simplify Data Layer Unit Testing using Enterprise Services de Roy Osherove). Cela nécessite d'avoir un provider ADO.NET qui supporte les transactions distribuées, ce qui est quand même le cas de bon nombre d'entre eux et nécessite d'exécuter que des commandes sql qui peuvent être utilisées dans une transaction distribuée.

Pour ma part, j'ai testé cette solution qui est plutot efficace et pas trop compliqué à mettre en place.

Cette solution a quand même un gros inconvénient, c'est que pendant son temps d'exécution, elle bloque toutes les requetes select qui n'ont pas de (nolock), ou les insert/update. Et ceci pour tous les autres utilisateurs également. (sql server)

[nicorama]

Avoir une base de données de test et exécuter chaque opération CRUD dans une transaction qui sera ensuite annulée. Cela nécessite de rajouter du code spécifique dans nos tests pour créer et annuler la transaction.

Et quand il y a un problème, je rebascule une bdd propre. L'avantage est qu'on peut tester les effets de bord : un test A se passe mal, mais n'est pas détecté. Le test B suppose que tout était comme avant, mais ce qu'a engendré A fait planter B.

Bonjour le casse-tête pour trouver que c'est A le responsable. On corrige, on rajoute le test d'effet de bord qui aurait du être fait dans A et on repart au combat.

[nico-pyright(c)]

quels sont les outils que vous utilisez pour remettre en état vos bases de données ?

[tyzef]

et qu'avez vous répondu alors ?

Bah justement pas grand chose ... d'où l'intérêt que j'ai à suivre ce post.

Disons que nous utilisons JUnit sur nos couches DAO (Hibernate). Mais nous développons plusieurs versions en parallèles, les structure des tables changent régulièrement et nous courrons un peu ces temps ci alors ... la classique gestion du temps (c'est de l'argent) ... et nos tests ne sont plus cohérents avec la/les bases.

Actuellement 100% de nos tests automatisés sont en échec et aucune ressource n'est dispo pour mettre à jour les classes de tests.

sinon vu l'instabilité des bases du client sur certaines couches, je pencherais pour une restauration de données spécifiques aux tests de chaque versions ... mais la base est très volumineuse et les avenants durant les phases de développements et jusqu'à la livraison sont réguliers (sans parler du manque de place à stocker les dumps)

Bref ... pas vraiment de réponse adaptée ...

Question subsidiaire : quels sont les apports de DBUnit par rapport à JUnit ?

[Philippe Vialatte]

Ok, j'arrive un peu tard...

Pour les tests qui tapent la Db, on a une db de test, qui n'est accédée que par le serveur díntegration continue pour les tests d'integration. Les tests unitaires ne tapent pas la db.

Dans le projet courant, ca ne pose pas trop de pb de ne faire les tests d'integration que depuis le serveur d'integration continue, ils tournent tous les soirs, et une modif dans la base de dev doit etre reportee dans la base de test.
Avant de fair tourner les tests, on a une tache qui fait un backup de la bdd, et apres le test, un restore de la bdd..

Comme la base est (relativement) stable et que l'équipe est petite, ca passe...

[nico-pyright(c)]

Avant de fair tourner les tests, on a une tache qui fait un backup de la bdd, et apres le test, un restore de la bdd..

Tu utilises un outil pour ca ?

les structure des tables changent régulièrement

C'est vrai que c'est toujours un peu galère de maintenir différentes structures, avec une base de dev qui peut être facilement perturbée et une base de test qui ne reflete pas forcément la dev à un instant T

[Philippe Vialatte]

Tu utilises un outil pour ca ?

Nant + une tache custom

http://weblogs.sqlteam.com/billg/arc...restoredb.aspx

[Maniak]

Pour les tests qui tapent la Db, on a une db de test, qui n'est accédée que par le serveur díntegration continue pour les tests d'integration. Les tests unitaires ne tapent pas la db.

Dans le projet courant, ca ne pose pas trop de pb de ne faire les tests d'integration que depuis le serveur d'integration continue, ils tournent tous les soirs, et une modif dans la base de dev doit etre reportee dans la base de test.
Avant de fair tourner les tests, on a une tache qui fait un backup de la bdd, et apres le test, un restore de la bdd..

Pareil, sauf qu'au lieu d'un backup/restore, il y a un script de création de la structure de la base et un autre pour insérer les données de référence (le minimum vital pour que la base soit utilisable quoi). NAnt aussi.
L'utilisation d'un script pour la structure a un avantage en parallèle qui est d'historiser l'évolution de la structure en permettant d'utiliser des outils comme SQLCompare pour synchroniser ces évolutions vers la base de qualif/préprod/production sans avoir à tout faire à la main.

Les tests d'intégration sont dans un projet séparé et sont lancés par le serveur d'intégration à intervalle régulier (toutes les 4h pour le moment), sur une base dédiée, recréée pour l'occasion. Ils sont exécutables aussi sur les postes de développeurs, du moment qu'ils ont au moins un SQLServer Express en local. Pour eux, il y a un 'test' explicite qui se charge de recréer la base de test en local, quand la structure ou que les données de référence changent, histoire que tout puisse se faire directement depuis VS.

Toutes les classes de test correspondantes dérivent d'une même base qui ouvre une transaction dans le [SetUp] et fait un rollback dans le [TearDown]. La classe de base expose un dérivé de l'UnitOfWork normal pour prendre la main sur la gestion des transactions, comme ça c'est transparent pour le reste.

Vu que les tests d'intégration sont limités à l'exécution des requêtes elles-mêmes (les Repositories concrets utilisant NHibernate), les tests restent généralement très simples. Dès qu'il s'agit de tester autre chose qu'un Repository, ça se fait via des tests unitaires normaux avec de faux repositories, sans dépendance sur NHibernate.

L'option SQLite pourrait être plus rapide et permettre éventuellement de lancer les tests d'accès en même temps que les tests unitaires, mais j'aime autant qu'ils s'exécutent sur une plate-forme la plus proche possible de l'appli en prod :)

Pas essayé NDbUnit, mais ça me semble un peu de l'overkill quand on a déjà ce qu'il faut pour créer une base de test, que le mécanisme de transaction est facilement utilisable et qu'on a des repositories dispos pour insérer facilement les données de test à la demande.

(au final, merci DDD et NHibernate :)

[nico-pyright(c)]

est-ce que vous avez déjà envisagé d'utiliser Visual Studio Database edition ?

[Immobilis]

Salut,

Pour ce qui est de tester la DAL, j'ai une architecture 3-Tiers assez robuste. Du coup il suffit de suivre le modèle et ça roule. En plus de la DAL, j'ai un objet de connexion assez pratique. Je teste toujours sur la même base sans la remettre en l'état. Elle est trop grosse.

Il ne me semble pas qu'il y ait 36 façons d'implémenter le CRUD. Au final, les requêtes sont les mêmes. Si on utilise des procédures stockées, qu'on utilise pas trop de connections, des DataReader plutôt que des DataSet, ne pas poser de verrous sur les SELECT (sauf si nécessaire)... Un CRUD peut être testé sur une table simple. Une fois qu'il fonctionne bien cela dépend de l'architecture de la base, des modèles qu'elle représente. Certaines des tables de notre base contiennent plus de 250 champs! On ne pouvait pas aller au delà sous SQL Server 2000

Les tests qui m'ont permis d'atteindre le niveau de performance souhaité on tourné autour des compteurs de performance de windows des serveur IIS et SQL.

Ensuite c'est du bon sens, ne charger que les données dont on a besoin. L'architecture de la base a aussi un role à jouer (index, etc).

A+