Comment effectuer un test unitaire sur la procédure de magasin à distance

Question

Je suis confronté à faire le test unitaire sur la couche d'accès aux données, toute la base de données d'appel de couche d'accès aux données via la procédure de stockage. Je prévois de créer une base de données propre utilisée pour les tests unitaires, mais j'ai trouvé que la plupart des procédures de stockage appelaient l'autre base de données, je ne sais pas comment tester ce type de procédure de stockage. ? ou d'autres solutions?

Answer 1

En général, plus vous pouvez abstraire votre couche d'accès aux données du reste de l'application, mieux vous pouvez la tester unitaire. Comme l'a écrit Jayden dans une autre réponse, Test Doubles tels que les simulacres dynamiques sont une bonne solution. Cependant, si j'ai bien compris votre question, vous voulez explicitement tester la couche d'accès aux données, et c'est également correct. Dans ce cas, les simulacres dynamiques ne vont pas vous aider, car vous testerez la couche la plus basse de votre application - il n'y a plus rien à faire. Certaines personnes insistent sur le fait qu'il ne s'agit pas d'un test mais plutôt d'un test d'intégration , mais je pense que la partie importante est de savoir si le test est automatisé ou non, et non ce que nous appelons. Dans tous les cas, une fois que vous avez commencé à tester la couche d'accès aux données, vous avez plus ou moins à traiter avec elle comme elle est. S'il utilise des procédures stockées à distance, vous devrez également gérer cela. Pour simplifier la configuration, vous pouvez placer la base de données 'remote' dans la même boîte que la base de données 'locale'.

Un test unitaire est principalement un test comportemental, ce qui serait correct. Il devrait y avoir d'autres types de tests (tests d'intégration ou tests système) qui utilisent une configuration réaliste avec de nombreuses machines distribuées, etc. pour vérifier que la sécurité, la mise en réseau etc. fonctionne comme prévu, mais cela ne devrait pas être l'objectif principal d'un test unitaire.

Answer 2

Regardez dans le mockage d'objet. Rhino mocks est une solution à ce problème, vous pouvez commencer à regarder here . Mocking vous permettra de simuler l'accès aux données à partir de votre base de données sans avoir à mettre en place une base de données 'test'. Il y a un peu de travail impliqué dans la mise en place des simulacres, mais cela maintient vos tests cohérents.

Answer 3

Vous pouvez envisager de structurer votre base de données en faisant référence à l'autre, de sorte que toutes les tables distantes accèdent via des vues. Je suis normalement une convention de dénomination de:

vw_[DATABASENAME]_[TABLENAME] 

La vue se compose de rien d'autre que:

select * from server.dbo.tablename 

Toutes les procédures stockées accès tables à distance via les points de vue, plutôt que directement par exemple pour accéder à une table Personne Le personnel d'appel de base de données distante serait:

create view vw_STAFF_Person 
as 

select * from Staff.dbo.Person 

go 

create procedure stp_Select_Staff 
as 

select * from vw_Staff_Person 

go 

plutôt que

create procedure stp_Select_Staff 
as 

select * from Staff.dbo.Person 

go 

La raison pour cela est que lorsque vous voulez tester votre base de données, vous voudrez probablement relier toutes les bases de données distantes à vos bases de données distantes 'test'. Cela est généralement plus facile à faire lorsque les seuls objets qui accèdent à des données distantes sont des vues simples, plutôt que des procédures stockées souvent plus nombreuses et complexes.

J'ai généralement un travail de configuration qui peut rescrire les vues aux bases de données 'test', donc c'est fait automatiquement. En plus de cela, j'ai souvent un travail de configuration qui restaure les sauvegardes de base de données de production dans l'environnement 'test' afin que les tests avant le déploiement puissent être effectués sur des systèmes qui contiennent une copie de données en direct. Encore une fois ce processus est rendu plus facile avec seulement avoir à relier les vues, plutôt que toutes les références proc stockées aux systèmes distants.

Afin de rendre les tests contre la sécurité plus facile, j'ai aussi toujours mis la sécurité de base de données au niveau de la base de données roles, plutôt que des utilisateurs spécifiques, que je trouve roles plus portable dans des environnements de production, de test et de développement que users.

Espérons que certains de ces conseils aident.