Création de Tests d'Intégration pour la Migration Oracle vers PostgreSQL

Génère des cas de test d'intégration pour les artefacts d'accès aux données dans un projet cible unique. Les tests valident la cohérence du comportement lors de l'exécution sur Oracle ou PostgreSQL.

Prérequis

• Le projet de test doit déjà exister et compiler (échafaudage effectué séparément).
• Lisez la classe de test de base existante et les conventions du gestionnaire de seed avant d'écrire des tests.

Workflow

Création de Test:
- [ ] Étape 1: Découvrir les conventions du projet de test
- [ ] Étape 2: Identifier les artefacts d'accès aux données testables
- [ ] Étape 3: Créer les données de seed
- [ ] Étape 4: Écrire les cas de test
- [ ] Étape 5: Examiner le déterminisme

Étape 1: Découvrir les conventions du projet de test

Lisez la classe de test de base, le gestionnaire de seed et le fichier projet pour comprendre les modèles d'héritage, la gestion des transactions et les conventions des fichiers de seed.

Étape 2: Identifier les artefacts d'accès aux données testables

Limitez-vous au projet cible uniquement. Listez les méthodes d'accès aux données qui interagissent avec la base de données — repositories, DAOs, appelants de procédures stockées, constructeurs de requêtes.

Étape 3: Créer les données de seed

• Respectez les conventions d'emplacement et de nommage des fichiers de seed du projet existant.
• Réutilisez les fichiers de seed existants quand c'est possible.
• Évitez TRUNCATE TABLE — conservez les données existantes de la base de données intactes.
• Ne commitez pas les données de seed ; les tests s'exécutent dans des transactions qui font un rollback.
• Assurez-vous que les données de seed ne créent pas de conflit avec d'autres tests.
• Chargez et vérifiez les données de seed avant que les assertions en dépendent.

Étape 4: Écrire les cas de test

• Héritez de la classe de test de base pour obtenir automatiquement la création/rollback de transaction.
• Affirmez les sorties logiques (lignes, colonnes, comptages, types d'erreur), pas les messages spécifiques à la plateforme.
• Affirmez des valeurs attendues spécifiques — n'affirmez jamais qu'une valeur est simplement non-null ou non-vide quand une valeur concrète est disponible à partir des données de seed.
• Évitez de tester des chemins de code qui n'existent pas ou d'affirmer un comportement qui ne peut pas se produire.
• Évitez les assertions redondantes entre les tests ciblant la même méthode.

Étape 5: Examiner le déterminisme

Réexaminez chaque assertion par rapport aux valeurs non-null. Confirmez que chacune est déterministe par rapport aux données seedées. Corrigez toute assertion qui dépend d'un état de base de données en dehors du contrôle du test.

Contraintes Clés

• Oracle est la source de référence — les tests capturent le comportement attendu d'Oracle.
• Assertions indépendantes de la BD — pas de messages d'erreur spécifiques à la plateforme ou de syntaxe dans les assertions.
• Seed uniquement sur Oracle — le projet de test sera migré vers PostgreSQL ultérieurement.
• Limité à un projet — ne créez pas de tests pour des artefacts en dehors du projet cible.