Tests unitaires pilotés par les données

Question

Quelle est la meilleure pratique pour tester une API qui repose sur les données de la base de données? Quels sont les problèmes à surveiller dans une "Intégration continue"? environnement qui exécute des tests unitaires dans le cadre du processus de construction? Je veux dire, déploieriez-vous votre base de données dans le cadre des scripts de construction (vous pouvez exécuter votre programme d’installation) ou devrais-je choisir des données codées en dur [utilisez les tests unitaires pilotés par MSTest avec XML]?

Je comprends que je peux me moquer de la couche de données pour la couche Business Logic, mais que se passe-t-il si je rencontrais des problèmes dans mes instructions SQL dans DAL? J'ai besoin de frapper la base de données, non?

Eh bien ... c'est un torrent de questions:) ... Des pensées?

Answer 1

Autant que possible, vous devriez simuler le code pour éviter de toucher la base de données, mais il me semble que vous avez raison de dire qu'il est nécessaire de tester votre code SQL à un moment ou à un autre. Si vous écrivez des tests qui touchent la base de données, un conseil important pour éviter les maux de tête est de vous assurer que votre configuration obtient les données dans un état connu, au lieu de vous fier aux données appropriées déjà disponibles.

Et bien sûr, ne testez jamais avec votre base de données live! Mais cela va sans dire:)

Answer 2

Comme mentionné précédemment, simulez les appels de base de données lors des tests unitaires à l'aide de mocking, à moins que vous ne vouliez modifier vos tests et vos données à l'infini. Tester des instructions SQL implique davantage un test d'intégration . Exécutez cela séparément des tests unitaires, ce sont 2 bêtes différentes.

Answer 3

C’est une bonne idée d’effacer automatiquement la base de données de tests, puis de la renseigner avec des données de faisceaux de tests qui seront supposées être présentes pour tous les tests devant se connecter à la base de données. La base de données doit être réinitialisée avant chaque test afin de garantir une isolation correcte. Un test qui échoue et qui incorpore des données incorrectes peut entraîner de faux échecs lors des tests suivants. Il devient donc gênant si vous devez exécuter des tests dans un certain ordre pour obtenir des résultats cohérents. >

Vous pouvez effacer et remplir la base de données avec des outils ( DBUnit , DBUnit.NET , autres) ou créez simplement vos propres classes d’utilitaires pour faire la même chose.

Comme vous l'avez dit, les autres couches doivent être suffisamment dissociées des classes qui atteignent réellement la base de données. Par conséquent, la nécessité d'impliquer tout type de base de données dans les tests est limitée aux tests exécutés sur un petit sous-ensemble de votre base de code. Votre base de données accédant aux composants peut être moquée / modifiée pour tout ce qui en dépend.

Answer 4

J'ai notamment créé des méthodes statiques renvoyant des données de test d'un état connu. J'utiliserais alors un "faux". DAL doit renvoyer ces données comme si j’appelais la base de données. En ce qui concerne le test de la procédure SQL / stockée, je l’ai testée à l’aide de SQL Management Studio. YMMV!