Question

Quelqu'un a-t-il de bons conseils pour écrire du code de test pour le développement back-end de base de données où il existe une forte dépendance à l'égard de l'état ?

Plus précisément, je souhaite écrire des tests pour le code qui récupère les enregistrements de la base de données, mais les réponses dépendront des données de la base de données (qui peuvent changer avec le temps).

Les gens créent-ils généralement un système de développement séparé avec une base de données « gelée » afin qu'une fonction donnée renvoie toujours exactement le même jeu de résultats ?

Je suis sûr que ce n'est pas un problème nouveau et je serais donc très intéressé d'apprendre de l'expérience des autres.

Existe-t-il de bons articles qui traitent de cette question du développement Web en général ?

J'écris habituellement du code PHP, mais je m'attendrais à ce que tous ces problèmes soient en grande partie indépendants du langage et du framework.

Était-ce utile?

La solution

Vous devriez consulter DBUnit ou essayer de trouver un équivalent PHP (il doit y en avoir un).Vous pouvez l'utiliser pour préparer la base de données avec un ensemble spécifique de données qui représente vos données de test, et ainsi chaque test ne dépendra plus de la base de données et d'un état existant.De cette façon, chaque test est autonome et ne sera pas interrompu lors d'une utilisation ultérieure de la base de données.

Mise à jour:Une recherche rapide sur Google a montré un Extension d'unité de base de données pour PHPUnit.

Autres conseils

Si vous êtes principalement préoccupé par les tests de couche de données, vous voudrez peut-être consulter ce livre : Modèles de test xUnit :Refactorisation du code de test.J'en ai toujours été moi-même incertain, mais ce livre fait un excellent travail pour aider à énumérer les problèmes tels que les performances, la reproductibilité, etc.

Je suppose que cela dépend de la base de données que vous utilisez, mais Red Gate (www.red-gate.com) crée un outil appelé SQL Data Generator.Cela peut être configuré pour remplir votre base de données avec des données de test d'aspect raisonnable.Vous pouvez également lui dire de toujours utiliser la même graine dans son générateur de nombres aléatoires afin que vos données « aléatoires » soient les mêmes à chaque fois.

Vous pouvez ensuite rédiger vos tests unitaires pour utiliser ces données fiables et reproductibles.

En ce qui concerne les tests du côté Web, j'étudie actuellement Selenium (selenium.openqa.org).Cela semble être une suite de tests compatible avec plusieurs navigateurs qui vous aidera à tester les fonctionnalités.Cependant, comme pour tous ces outils de test de sites Web, il n'existe aucun moyen réel de tester l'efficacité de ces éléments. regarder dans tous les navigateurs sans y jeter un œil humain !

Nous utilisons une base de données en mémoire (hsql : http://hsqldb.org/).Hiberner (http://www.hibernate.org/) nous permet de pointer facilement nos tests unitaires vers la base de données de test, avec l'avantage supplémentaire qu'ils s'exécutent aussi vite que l'éclair.

J'ai exactement le même problème avec mon travail et je trouve que la meilleure idée est d'avoir un script PHP pour recréer la base de données, puis un script séparé dans lequel je lui lance des données folles pour voir si cela la casse.

Je n'ai jamais utilisé de tests unitaires ou autres, je ne peux donc pas dire si cela fonctionne ou non, désolé.

Si vous pouvez configurer la base de données avec une quantité connue avant d'exécuter les tests et la supprimer à la fin, vous saurez alors avec quelles données vous travaillez.

Ensuite, vous pouvez utiliser quelque chose comme Selenium pour tester facilement à partir de votre interface utilisateur (en supposant que ce soit basé sur le Web ici, mais il existe de nombreux outils de test d'interface utilisateur pour d'autres versions d'interface utilisateur) et détecter la présence de certains enregistrements extraits de la base de données.

Cela vaut vraiment la peine de configurer une version de test de la base de données ou de faire en sorte que vos scripts de test remplissent la base de données avec des données connues dans le cadre des tests.

Tu pourrais essayer http://selenium.openqa.org/ il s'agit davantage d'un test d'interface graphique que d'une application de test de couche de données, mais il enregistre vos actions qui peuvent ensuite être lues pour automatiser les tests sur différentes plates-formes.

Voici ma stratégie (j'utilise JUnit, mais je suis sûr qu'il existe un moyen de faire l'équivalent en PHP) :

J'ai une méthode qui s'exécute avant tous les tests unitaires pour une classe DAO spécifique.Il met la base de données de développement dans un état connu (ajoute toutes les données de test, etc.).Pendant que j'exécute des tests, je garde une trace de toutes les données ajoutées à l'état connu.Ces données sont nettoyées à la fin de chaque test.Une fois tous les tests de la classe exécutés, une autre méthode supprime toutes les données de test de la base de données de développement, la laissant dans l'état dans lequel elle se trouvait avant l'exécution des tests.Faire tout cela demande un peu de travail, mais j'écris généralement les méthodes dans une classe DBTestCommon où toutes mes classes de test DAO peuvent y accéder.

Je proposerais d'utiliser trois bases de données.Une base de données de production, une base de données de développement (remplie de données significatives pour chaque développeur) et une base de données de test (avec des tables vides et peut-être quelques lignes toujours nécessaires).

Une façon de tester le code de la base de données est la suivante :

  1. Insérez quelques lignes (en utilisant SQL) pour initialiser l'état
  2. Exécutez la fonction que vous souhaitez tester
  3. Comparez les résultats attendus avec les résultats réels.Ici, vous pouvez utiliser votre cadre de tests unitaires normal
  4. Nettoyez les lignes qui ont été modifiées (afin que la prochaine exécution ne voie pas l'exécution précédente)

Le nettoyage pourrait être effectué de manière standard (bien sûr, uniquement dans la base de données de test) avec DELETE * FROM table.

En général, je suis d'accord avec Peter mais pour créer et supprimer des données de test, je n'utiliserais pas directement SQL.Je préfère utiliser une API CRUD utilisée dans le produit pour créer des données aussi similaires que possible à la production...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top