SGBD en mémoire pour les tests unitaires

Question

Je recherche des options satisfaisantes pour le test unitaire de mes classes .NET DAL; S'agissant de classes DAL, ils accèdent directement à la base de données à l'aide de ADO.NET. Actuellement, j'utilise une instance d'une base de données MSSQL pour les tests, mais je me demandais quelles étaient les options les plus rapides: puisque les tests unitaires doivent s'exécuter le plus rapidement possible, une solution en mémoire serait idéale.

Je dois également mentionner que je me suis attaché à TSQL, car je n'utiliserai jamais qu'une plate-forme Microsoft.

Answer 1

Étant donné que vous déclarez:

  

Je devrais également mentionner que j'ai attaché   moi-même à TSQL depuis que je ne suis jamais   va utiliser un Microsoft   plate-forme.

Ensuite, l’utilisation de SqlServer compact Edition peut convenir à vos besoins. Il ne fonctionnera pas entièrement en mémoire, mais peut fonctionner en mode lecture seule (aucune modification n’est apportée au fichier principal de la base de données, de sorte qu’il puisse être utilisé simultanément par plusieurs tests.

Il y a quelques pièges, aucune procédure stockée n'est prise en charge, quelques types de données doivent être traduits et certains types de données ont des limites strictes (notamment varchar qui ne peut contenir que 4 000 caractères). Linq to Sql n'est également pas correctement pris en charge.

Néanmoins, j'ai utilisé SqlServer Compact Edition pour remplacer presque entièrement la base de données Sql Server appropriée avec de bons résultats.

Answer 2

J'ai trouvé SQLite la meilleure option. Bien que j'utilise nHibernate, mais sa configuration est nulle et sa configuration ne prend que quelques secondes. Cependant, vous devez savoir que ces types de moteurs manquent généralement de certains éléments nécessaires (par exemple, SQLite explose lorsque vous avez des espaces dans les noms de table si vous utilisez un fournisseur ADO)

.

D'accord, @TopBanana a raison sur certains problèmes liés à la non-utilisation d'un & "vrai &"; base de données. Cependant, un SGBDR en mémoire convient parfaitement aux types de tests que vous souhaitez exécuter très rapidement (par exemple, des tests d’archivage pour les versions incrémentielles ou CI).

L’autre avantage non négligeable est que vous n’avez pas à vous soucier de la configuration ou du démantèlement. Il est extrêmement improductif que votre enregistrement échoue parce que le développeur A a cassé votre base de données dev; -)

Answer 3

Je vous recommanderais d'utiliser la même base de données pour vos tests unitaires que pour la production. Vous n'avez vraiment pas besoin d'une différence étrange qui vous tire dans le pied lorsque vous déboguez un problème en direct.

Si vous jetez un coup d'œil à la très grosse suite de tests unitaires de NHibernate, vous verrez qu'elle utilise SQL Server (sur disque) et que les tests se déroulent étonnamment vite. Il est encore plus impressionnant de considérer qu’il ya beaucoup plus de création / suppression de table en cours que la moyenne des tests unitaires, ce qui n’est pas ce pour quoi SQL Server est optimisé.

Answer 4

J'ai entendu dire qu'il existe un logiciel pour monter un disque mémoire dans Windows (je ne me souviens pas de l'URL, désolé).

Il pourrait être intéressant de créer des bases de données de test à ce sujet.

Answer 5

SQL Server est-il vraiment le goulot d'étranglement de vos tests unitaires?

je veux dire:

1. Avez-vous profilé vos tests unitaires (avec quelque chose comme SQL Profiler). Sont-ils tous lents? Quelques-uns sont lents? Pourquoi?
2. Vos tests unitaires en font-ils trop? Le code d'installation et de démontage est-il trop lourd?
3. Si SQL est votre goulet d’étranglement, avez-vous envisagé un cadre moqueur ? simulez tous vos appels SQL.

Answer 6

J'ai eu des problèmes similaires avec Oracle et nous avons procédé comme suit:

• s'est assuré que les tests unitaires réels ne touchaient pas la base de données, mais utilisaient plutôt des simulacres pour des services

• Les tests de base de données balisés qui nécessitaient réellement Oracle par rapport aux tests pouvant être exécutés sur HSQLDB, H2 ou tout autre système en mémoire. Nous pouvons donc les exécuter séparément.

• Lors des tests utilisant réellement les fonctionnalités Oracle, nous avons utilisé une instance Oracle normale exécutée sur un disque RAM.

Cela a considérablement accéléré les tests.