Skip to content
My Docs

Tests and Business Rules

The SIM Database ships with a pgTAP regression suite in tests/. Every test file runs in its own transaction; make test executes each file through psql inside the PostgreSQL container.

Test tooling

Section titled “Test tooling”
Component Purpose
tests/runner.sh Loops over /tests/*.sql and reports PASS/FAIL per file
docker/postgres/Dockerfile Compiles pgTAP 1.3.4 into the Alpine image
make test Starts/migrates the database then runs tests/runner.sh

Test files follow the pattern <number>_regles_<domain>.sql.

Business rules summary

Section titled “Business rules summary”
Rule Domain Statement
R1 Client Single client repository used by all modules
R2 Résidence Monthly rent dues are generated automatically for active/terminated contracts
R3 Résidence Contract statuses are constrained and numero_contrat is mandatory
R4 Résidence Housing types and statuses are constrained
R5 Pressing Pressing order statuses and line quantities are constrained
R6 Salle de fête Party-room reservation statuses and duration are constrained
R7 Market A sale decrements stock; quantities are positive
R8 Finances Every payment is tied to an activity and optionally to a residence due
R9 Finances Activities feed finance; no orphan invoices
R10 RH montant_a_payer = salaire_base + primes + heures_sup - retenues - avances
R11 RH Attendance arrival/departure times and duration are computed
R12 Résidence Deposit history is tracked
R13 Transverse Reference catalogs are configurable without code changes
R14 Finances Payment methods are configurable
R15 Audit Every business operation is traced in audit.journal_audit
R16 Market Stock alert thresholds work and stock cannot go negative
R17 Finances Payments are applied to invoices or residence dues

Test files

Section titled “Test files”
File Rules checked Notes
000_smoke.sql Tooling Confirms pgtap loads and the database is reachable
010_regles_transverses.sql R1, R8, R9, R14, R15, R17 Client, finance and audit invariants
020_regles_residence.sql R2–R4, R8, R12, R13 Static residence schema checks
030_regles_market.sql R7, R16 Static market schema checks
040_regles_pressing_restaurant_fete.sql R5, R6 Status and quantity constraints
050_regles_rh.sql R10, R11 Static HR schema checks
060_regles_dynamiques_residence.sql R2 generer_echeances, reviser_loyer, encaisser_loyer, views
070_regles_dynamiques_market.sql R7, R16 Stock movement triggers and views
080_regles_dynamiques_finances.sql R8, R17 Payment application and dashboard views
090_regles_dynamiques_rh.sql R10, R11 Payroll recalculation and attendance
100_audit.sql R15 Trigger logging and password masking
110_auth.sql Tokens Refresh-token table structure and no audit trigger
120_resident_portal.sql M2.5 Resident account scoping and one-account-per-client

Key dynamic checks

Section titled “Key dynamic checks”
  • R2 generer_echeances creates one echeance_loyer per month from contract start to current/next month.
  • R7 ENTREE adds stock, SORTIE removes stock; a SORTIE that would go negative is rejected.
  • R10 rh.recalculer_paie updates total_elements, total_retenues and montant_a_payer whenever rh.element_salaire changes; PAYEE and ANNULEE payslips are frozen.
  • R15 INSERT, UPDATE and DELETE on business tables produce one audit.journal_audit row; mot_de_passe is masked to ***.
  • R17 Inserting into finances.application_paiement recalculates facturation.facture.montant_paye, reste and statut automatically.