Question Comment faire des tests d'unité de base de données?


J'ai entendu dire que lors du développement d'une application qui utilise une base de données, vous devez effectuer des tests d'unité de base de données. Quelles sont les meilleures pratiques en matière de test d'unité de base de données? Quelles sont les principales préoccupations lors des tests unitaires de la base de données et comment le faire "correctement"?


37
2017-09-22 17:43


origine


Réponses:


Quelles sont les meilleures pratiques en matière de test d'unité de base de données?

le DbUnit framework (un framework de test permettant de mettre une base de données dans un état de connaissance et d'effectuer des assertions sur son contenu) a un test de base de données les meilleures pratiques cela, à mon expérience, est vrai.

Quelles sont les principales préoccupations lors des tests unitaires de base de données

  • Création d'un schéma à jour, gestion des modifications de schéma
  • Mise en place de données (données de référence, données de test) et maintenir données de test
  • Garder les tests indépendants
  • Permettre aux développeurs de travailler simultanément
  • Vitesse (les tests impliquant une base de données sont généralement plus lents et vont prendre plus de temps)

et comment le faire "bien"?

Comme suggéré, suivez les bonnes pratiques connues et utilisez des outils / frameworks dédiés:

  • Préférez dans la base de données de mémoire si possible (pour la vitesse)
  • Utiliser un schéma par développeur est indispensable (pour permettre un travail simultané)
  • Utiliser un outil de "migration de base de données" (à la RoR) pour gérer les modifications de schéma et mettre à jour un schéma vers la version finale
  • Construire ou utiliser un harnais de test permettant de placer la base de données dans un état connu avant chaque test et d'exécuter des assertions sur les données après l'exécution (ou d'exécuter des tests dans une transaction que vous annulez à la fin du test).

33
2017-09-22 18:17



Une liste des éléments à examiner et à prendre en compte lors du test des unités de base de données

  • Chaque testeur a besoin d'une base de données séparée, afin d'éviter d'interférer avec les activités d'un autre testeur / développeur
  • Avoir un moyen simple de créer une base de données à tester (ceci est lié à la présence d'une base de données SQL Server sous contrôle de version). Ceci est particulièrement utile lorsque vous essayez de trouver ce qui ne va pas si certains tests échouent
  • Concentrez-vous sur des domaines spécifiques et créez des tests pour un seul module au lieu de les couvrir tous en même temps. L'ajout de tests de manière granulaire est un bon moyen d'être efficace
  • Assurez-vous de fournir autant de détails que possible lorsqu'un test échoue, afin de faciliter le débogage
  • Utilisez les mêmes données de test pour tous les tests

Si test est implémenté à l'aide du framework tSQLt, le processus de test unitaire peut être compliqué lorsque vous traitez de nombreuses bases de données à partir de plusieurs instances SQL Server. Afin de maintenir, exécuter et gérer les tests unitaires directement à partir de SQL Server Management Studio, Test d'unité ApexSQL peut être utilisé comme une solution


11
2017-08-18 15:56



Jeter un coup d'œil à ce lien. Il aborde certaines des bases de la création de procédures stockées dans SQL Server, ainsi que les différents types de tests unitaires et leur utilisation. Je ne suis pas sûr du SGBD que vous utilisez, mais évidemment cet article est orienté vers SQL Server.

Volé de l'article:

Tests de fonctionnalités

Le premier et probablement le plus répandu   classe de test unitaire de base de données est un   test de fonctionnalité. Dans mon esprit, fonctionnalité   les tests testent les fonctionnalités principales ou les API,   si vous êtes de votre base de données du   perspective du consommateur de base de données.   Tester la programmabilité d'une base de données   objets est le scénario principal ici.   Donc, tester toutes les procédures stockées,   fonctions, et déclenche à l'intérieur de votre   base de données constituent des tests de fonctionnalité dans   mon esprit. Pour tester une procédure stockée,   vous exécuteriez la procédure stockée   et vérifier que soit le prévu   les résultats ont été retournés ou le   le comportement approprié s'est produit.   Cependant, vous pouvez tester plus que de simples   ces types d'objets. Vous pouvez   imaginer vouloir faire en sorte qu'une vue,   par exemple, renvoyer le bon   calcul à partir d'une colonne calculée. Comme   vous pouvez voir, les possibilités dans ce   le royaume est grand.

Tests de schéma

L'un des aspects les plus critiques d'un   la base de données est son schéma, et le test à   assurez-vous qu'il se comporte comme prévu est   une autre classe importante de base de données   tests unitaires. Ici, vous voudrez souvent   pour s'assurer qu'une vue renvoie le   ensemble attendu de colonnes du   type de données approprié dans le   ordre approprié. Tu pourrais vouloir   Assurez-vous que votre base de données le fait, en   fait, contient les 1000 tables qui   vous vous attendez.

Tests de sécurité

Dans le jour et l'âge d'aujourd'hui, la sécurité   des données stockées dans le   la base de données est critique. Ainsi, un autre   classe importante de tests unitaires de base de données   sont ceux qui testent la base de données   Sécurité. Ici, vous voudrez   s'assurer que des utilisateurs particuliers existent dans   votre base de données et qu'ils sont   affecté les autorisations appropriées.   Vous aurez souvent envie de créer des négatifs   tests qui tentent de récupérer des données   des tables ou des vues restreintes et   s'assurer que l'accès est   nié de manière appropriée.

Tests de stock-données

De nombreuses bases de données contiennent des données de stock ou   données de semences. Ces données changent   rarement et est souvent utilisé comme   rechercher des données pour des applications ou terminer   utilisateurs. Codes postaux et leurs associés   les villes et les États sont de bons exemples   de ce type de données. Il est donc   utile pour créer des tests pour s'assurer que   vos données de stock existent en fait   dans votre base de données.


8
2017-09-22 17:52



Je suis heureux que vous ayez posé des questions sur les tests unitaires et non sur les tests en général.

Les bases de données ont de nombreuses fonctionnalités à tester. Quelques exemples:

  • Types de données / taille / jeux de caractères (essayez d'insérer un nom suédois, ou des url longs ou des numéros du monde réel, et vérifiez si vos définitions de colonne sont correctes)
  • Déclencheurs
  • Contraintes (clés étrangères, unicité ...)
  • Vues (vérifiez que les données sont correctement incluses / exclues / transformées)
  • Procédures stockées
  • UDF
  • Autorisations
  • ...

Ceci est utile non seulement lorsque vous modifiez quelque chose dans votre base de données, mais également lorsque vous mettez à niveau vos dbms ou modifiez quelque chose dans vos paramètres.

Généralement, le test d'intégration est effectué. Cela signifie qu'une suite de tests dans un langage de programmation tel que PHP ou Java est créée et que les tests génèrent des requêtes. Mais si quelque chose échoue ou s'il existe des exceptions, il est plus difficile de comprendre le problème pour deux raisons:

  • Le problème pourrait être dans votre code PHP, ou dans la configuration PHP, ou sur le réseau, ou ...
  • Les instructions SQL sont plus difficiles à lire et à modifier si elles sont incorporées dans un autre langage de programmation.

Donc, à mon avis, pour les bases de données complexes, vous devez utiliser un framework de test unitaire écrit en SQL (en utilisant des procédures stockées et des tables). Vous devez le choisir avec soin, car ce type d’outils n’est pas largement utilisé (et donc peu testé). Par exemple, si vous utilisez MySQL, je connais ces outils:


3
2018-05-22 11:21



J'utilise junit / nunit / etc et code des tests unitaires de base de données avec java ou c #. Celles-ci peuvent alors être exécutées sur un serveur d'intégration en utilisant éventuellement un schéma distinct pour la base de données de test.

Le dernier développeur Oracle Oracle est livré avec un framework de test unitaire intégré. J'y ai jeté un coup d'oeil mais NE PAS utilise le. Il utilise une interface graphique pour créer et exécuter des tests et stocke tous les tests de la base de données, ce qui ne facilite pas la mise en place de scénarios de test sous contrôle de version. Il y a probablement d'autres frameworks de test que je pense qu'ils pourraient être spécifiques à votre base de données.

Les bonnes pratiques sont similaires aux tests unitaires réguliers:

  • mettre les tests sous contrôle de source
  • faire des tests rapides - ne pas tester trop à la fois
  • faites vos tests reproductible

2
2017-09-22 17:56



Jetez un coup d'oeil sur le framework DBTestDriven. Cela fonctionne très bien pour nous. Téléchargez-le depuis GitHub ou leur site web.


1
2017-11-07 21:56



En ce qui concerne le développement JVM, les tests unitaires peuvent tirer parti du résumé JDBC: dès que vous savez quelles données JDBC sont générées par un accès DB, ces données JDBC peuvent être "relues".

Ainsi, le cas d'accès à la base de données peut être «reproduit» pour le test, sans la base de données cible: pas de complexité de test / isolation des données, facilitant l'intégration continue.

Acolyte est un cadre utile de cette manière (y compris un outil graphique de studio pour "enregistrer" le résultat de la base de données): https://github.com/cchantep/acolyte


0
2018-01-06 09:26