La SIM Database embarque une suite de régression pgTAP dans tests/. Chaque fichier de test s’exécute dans sa propre transaction ; make test exécute chaque fichier via psql dans le conteneur PostgreSQL.
| Composant |
Rôle |
tests/runner.sh |
Itère sur /tests/*.sql et rapporte PASS/FAIL par fichier |
docker/postgres/Dockerfile |
Compile pgTAP 1.3.4 dans l’image Alpine |
make test |
Démarre/migre la base puis exécute tests/runner.sh |
Les fichiers de test suivent le patron <numéro>_regles_<domaine>.sql.
| Règle |
Domaine |
Énoncé |
| R1 |
Client |
Référentiel client unique utilisé par tous les modules |
| R2 |
Résidence |
Les échéances de loyer mensuelles sont générées automatiquement pour les contrats actifs/résiliés |
| R3 |
Résidence |
Les statuts de contrat sont contraints et numero_contrat est obligatoire |
| R4 |
Résidence |
Les types et statuts de logement sont contraints |
| R5 |
Pressing |
Les statuts de commande pressing et les quantités de ligne sont contraints |
| R6 |
Salle de fête |
Les statuts de réservation et la durée sont contraints |
| R7 |
Market |
Une vente décrémente le stock ; les quantités sont positives |
| R8 |
Finances |
Chaque paiement est lié à une activité et optionnellement à une échéance résidence |
| R9 |
Finances |
Les activités alimentent les finances ; pas de factures orphelines |
| R10 |
RH |
montant_a_payer = salaire_base + primes + heures_sup - retenues - avances |
| R11 |
RH |
Les heures d’arrivée/départ et la durée de présence sont calculées |
| R12 |
Résidence |
L’historique des cautions est suivi |
| R13 |
Transverse |
Les catalogues de référence sont configurables sans changement de code |
| R14 |
Finances |
Les moyens de paiement sont configurables |
| R15 |
Audit |
Chaque opération métier est tracée dans audit.journal_audit |
| R16 |
Market |
Les seuils d’alerte de stock fonctionnent et le stock ne peut pas devenir négatif |
| R17 |
Finances |
Les paiements sont appliqués aux factures ou échéances résidence |
| Fichier |
Règles vérifiées |
Notes |
000_smoke.sql |
Outillage |
Confirme que pgtap se charge et que la base est joignable |
010_regles_transverses.sql |
R1, R8, R9, R14, R15, R17 |
Invariants client, finances et audit |
020_regles_residence.sql |
R2–R4, R8, R12, R13 |
Contrôles statiques du schéma résidence |
030_regles_market.sql |
R7, R16 |
Contrôles statiques du schéma market |
040_regles_pressing_restaurant_fete.sql |
R5, R6 |
Contraintes de statut et quantité |
050_regles_rh.sql |
R10, R11 |
Contrôles statiques du schéma RH |
060_regles_dynamiques_residence.sql |
R2 |
generer_echeances, reviser_loyer, encaisser_loyer, vues |
070_regles_dynamiques_market.sql |
R7, R16 |
Triggers de mouvement de stock et vues |
080_regles_dynamiques_finances.sql |
R8, R17 |
Application de paiement et vues du tableau de bord |
090_regles_dynamiques_rh.sql |
R10, R11 |
Recalcul de paie et présences |
100_audit.sql |
R15 |
Journalisation par trigger et masquage des mots de passe |
110_auth.sql |
Jetons |
Structure de la table refresh-token et absence de trigger d’audit |
120_resident_portal.sql |
M2.5 |
Périmètre des comptes résidents et un compte par client |
- R2
generer_echeances crée une echeance_loyer par mois du début du contrat au mois courant/suivant.
- R7
ENTREE ajoute du stock, SORTIE en retire ; une SORTIE qui passerait en négatif est rejetée.
- R10
rh.recalculer_paie met à jour total_elements, total_retenues et montant_a_payer à chaque changement de rh.element_salaire ; les bulletins PAYEE et ANNULEE sont figés.
- R15
INSERT, UPDATE et DELETE sur les tables métier produisent une ligne audit.journal_audit ; mot_de_passe est masqué en ***.
- R17 Une insertion dans
finances.application_paiement recalcule automatiquement facturation.facture.montant_paye, reste et statut.
