Gestion des tests dans les bases de données avec Visual Studio

Nous arrivons au 3^ème et dernier article traitant de la gestion de la base de données dans Visual Studio 2010.

Il est temps de finir cet article vu que je suis passé à la nouvelle version de VS et il va donc falloir que je teste les évolutions de ce système.

Nous avions vu précédemment :

1. Comment créer sa solution et importer sa base de données dans Visual Studio
2. Comment déployer les nouvelles modifications sur la base

Aujourd’hui, nous allons voir comment exploiter votre projet de base de données dans vos tests automatisés.

Votre projet de base de données peut vous permettre de remplir votre base de données avant d’exécuter vos tests automatisés.

Nous allons donc présenter :

1. Les prérequis
2. Les types de données que nous pouvons injecter
3. La marche à suivre pour insérer des données
4. Comment brancher à cette alimentation des tests.

Les prérequis

Quelque soit le type de données que vous souhaitez, vous avez obligatoirement besoin d’une base de données ayant un modèle à jour (table, vues, fonctions,…).

Si ce n’est pas le cas, vous pouvez rapidement en générer une avec le comparateur de schéma :

1. Créer une base vide
2. Comparer la avec votre projet
3. Déployer

Sinon, il se peut que vous ayez besoin d’une base de données figée (à jour avec des données métier) si vous voulez faire des tests métier. Nous allons vous présenter son utilité dans la partie suivante.

Les types de données que nous pouvons injecter

Il existe 2 types de données injectables dans une base de données de test qui sont gérer par les objets suivants :

• Data Generation Plan
• Data Transform Plan

Ils rangent tous les 2 dans le dossier « Data Generation Plan » de l’arborescence.

Data Generation Plan

Cet objet était déjà propose dans la version précédente de VS et permet de générer des données aléatoires dans les tables.

Il est donc très intéressant pour générer un volume de données et ainsi tester la performance de la base.

Data Transform Plan

Ce second outil est quant à lui un copieur de données. Il ne génère pas de données mais va les copier à partir d’une autre base (d’où l’utilité d’une base de données figée).

Cet outil est donc parfait pour les tests métier car vous pouvez facilement maitriser les données vu qu’elles viennent d’une base que vous avez préalablement alimentée.

Lequel choisir ?

Ceci dépend de vos besoins. Choisissez celui qui vous intéresse en fonction du type de test souhaité :

Le Data Tranform Plan pou les tests métier ou le data Generation Plan pour les tests de performance

Quelque soit votre choix la marche à suivre pour l’insertion de données sera pratiquement la même.

La marche à suivre pour insérer des données

Pour gérer le volume d’information que vous voulez injecter, il vous suffit de cocher ou décocher les tables. On notera que les tables liées par des clés étrangères seront aussi sélectionné automatiquement pour permettre l’insertion des données.

Pour chaque table vous pouvez choisir, le nombre de ligne et vous pouvez avoir un aperçu du résultat.

Vous pouvez à présent générer des données dans votre base de test. Nous pouvons donc maintenant connecter cette génération de données à nos tests.

Comment brancher à cette alimentation des tests.

Les données que nous venons de générer sont utilisables initialement pour les tests SQL mais nous allons pouvoir voir qu’il st possible de les connecter à des tests du code applicatif standards.

Test de la base de données

Pour utiliser des tests, il faut choisir le générateur à la création du test SQL :

Vous pouvez ensuite écrire la syntaxe de votre code SQL que vous voulez tester.

Ensuite, il faut choisir les tests que l’on souhaite faire :

On remarque ici que les tests s’exécutent l’un après l’autre donc si le 1^eréchoue il est impossible de savoir si d’autres après celui-ci ont échoué aussi.

De plus, l’interface est assez compliquée quand on cherche à tester une valeur scalaire dans un DataSet. Il semble difficile de saisir le test sur un tableau complet et impossible sa maintenance. Cela reviendrait à une partie de bataille navale lors de sa correction…

Il faut donc faire des tests simples, tester le nombre de ligne et ne tester qu’une ou 2 valeurs maximum.

Test du code applicatif

Par défaut, le générateur de données alimente la base pour un test de base de données. Il s’avère que le code généré derrière les tests de base sont en C#.

Il est donc tout à fait possible de reprendre les parties du code qui aliment la base pour les réexploiter dans vos tests qui appellent les classes de votre projet de code applicatif.

Conclusion générale sur la gestion de la base de données sur Visual Studio

Visual Studio nous propose un outil qui a pour ambition de répondre à la gestion du sourcing de la base de données, de la livraison des mises à jour et l’exécution de tests avec la base de données.

J’utilise cet outil régulièrement dans mes différentes missions mais je trouve qu’il présente certaines limites :

• Gestion en fichier de l’arborescente sans rangement automatique
• Déploiement rapide du code impossible
• Il faut obligatoirement comparer pour générer le code à livrer. La solution ne des que CREATE sans savoir un raccourci pour injecter rapidement les mises à jour en base
• Si les solutions sont titanesques avec de multiples connexions entre bases de données la solution deviendra trop volumineuse et vous aurez des crash mémoire durant son lancement
• Le générateur de données n’est pas assez stable (quitte ou double sans raison) et ne fourni pas d’explication sur les raisons de son échec…

Malgré ces défauts, je retiens cet outil car il propose 2 points majeurs solides :

• Le versionning de la base de données qui est directement branché à TFS comme du code applicatif et tous les intérêts qui en découlent
• Le comparateur de schéma qui permet de comparer des bases de données et des projets très facilement et la génération du script à livrer très facile d’utilisation

De plus, je pense que les améliorations majeures au-delà de la correction des défauts précédemment cités sont à mes yeux :

• Logique objet dans la navigation ce qui devrait être possible vu que VS arrive à compiler le code et donc les objets…
• Pouvoir exporter sous Excel la comparaison de schéma afin de pouvoir la communiquer facilement à toute l’équipe.

J’en ai donc fini avec la présentation de cet outil. Maintenant que j’ai sous la main sur la nouvelle version de Visual studio, je vais contrôler ce qui a changé dans cet outil.