essais dans un cadre d'application soutenue de base de données modulaire/enfichables

Question

Contexte

Actuellement avec un cadre d'application sauvegardé base de données modulaire: la mémoire de données est une couche mince sur une Postgres régulière, et les modules/modules externes peut dépendre d'un une autre et effectuer des opérations relativement arbitraires sur ladite base de données, y compris l'ajout de colonnes ou de modifier leurs propriétés (par exemple, faire une colonne de dépendance NOT NULL), permettant ainsi un module se compose de

1. appliquant son DDL (nouvelles tables, de nouvelles colonnes, de nouvelles contraintes , nouveaux index, modifications aux versions existantes de l'un des précédents, ...)
2. l'installation des données « statiques » qu'il contient
3. en option en cours d'exécution de ses essais

Problème

Cela conduit à test être une corvée, le système actuel doit installer un module puis exécutez ses tests avant de pouvoir passer au module suivant, ce qui nécessite essentiellement de réinitialiser le système à 0 afin de réexécuter les tests (un module K ayant modifié le schéma DB de telle sorte que les tests du module J ne fonctionnent plus) . Il est lourd, gênant, lent et difficile à intégrer aux outils de test ou aux méta-outils existants.

Recherche

je cherche en ce qui en fait moins gênant, mais en dehors de sauter des modules (le système actuel n'a aucune notion de « modules pour tester », seuls « modules à installer », et sur essayer de tester un module il exécutera également des tests pour toutes ses dépendances) Je n'ai pas réussi à trouver quoi que ce soit.

Answer 1

Tant que vous gardez les changements dans un schéma, cela devrait être facile (à moins que je ne comprenne pas vos besoins correctement). Avant chaque test, vous devez réinitialiser la base de données. une idée simple serait de laisser tomber et de créer le schéma à nouveau. Si vous devez réinitialiser db à un état prédéfini, vérifiez les modèles postgres. Si votre outil doit permettre des opérations db complètement personnalisées comme la suppression d'utilisateurs ou de schémas, vous aurez besoin d'un type de couche d'abstraction qui garde trace de la connexion à cette base de données après tous ces changements (user, passwd, jdbc url).

La plupart des projets existants pour les tests d'intégration ne sont pas conçus pour tester les modifications de schéma, mais plutôt pour tester comment le code coopère avec un schéma fixe.

Je ne connais pas d'autre projet qui offre tout ce dont vous avez besoin, donc ce sera un marketing éhonté. récemment, j'ai créé un outil pour les tests d'intégration testegration. c'est un produit commercial mais a un niveau libre. il a également été conçu pour tester un schéma fixe mais il devrait gérer votre cas - il suffit de remplacer la phase 'reset' pour utiliser le schéma drop/create ou l'utilisation du template postgres