Testing Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• test-inventory-intake.sh
• tests/event-desk-integration.spec.ts
• tests/dashboard-data-processing.unit.test.ts
• tests/data-processing-vitest.test.ts
• testsprite_tests/TC012_Server_side_enforced_route_protection_and_permission_validation.py
• CHECKLIST_PRECOMMIT.md
• CHECKLIST_PRERELEASE.md

The DRX CRM project employs a multi-layered testing strategy designed to ensure data integrity, security compliance, and UI responsiveness. The strategy spans from low-level unit tests for data processing logic to high-level end-to-end (E2E) integration tests and automated security audits. This comprehensive approach ensures that critical business paths—such as inventory intake, sales processing, and credit management—remain functional and secure across updates.

Sources: README.md:144-153, CHECKLIST_PRERELEASE.md:10-14

Testing Architecture and Tiers

The project categorizes testing into four distinct phases to validate different aspects of the system.

Tier	Tooling	Focus Area
Unit Testing	Vitest	Data processing logic, cost calculations, and metric aggregations.
Integration Testing	Playwright	End-to-end data flow between the UI and backend services.
Security/Compliance	TestSprite / Python	Role-based access control (RBAC) and route protection.
Database/Schema	Bash / PSQL	Schema verification, table existence, and helper function validity.

Sources: README.md:65-71, test-inventory-intake.sh:1-131, tests/data-processing-vitest.test.ts:10-15

Automated Test Workflow

The following diagram illustrates the automated test flow from local development to pre-release.

Unit Testing Strategy

Unit tests focus on the isolation of business logic, specifically processing functions that handle sales data, inventory alerts, and credit outstanding calculations.

Data Processing Logic

Core processors such as EventDeskProcessor, DashboardProcessor, and IntakeProcessor are tested for mathematical accuracy and edge-case handling (e.g., null values, empty datasets, or large numbers).

• Cost Calculations: Verifies cost-per-gram accuracy to 6+ decimal places (e.g., $1200 / 1000g = 1.200000$).
• Metric Aggregation: Ensures that 30-day sales windows and total credit outstanding are calculated correctly from raw arrays.
• Inventory Intake: Validates new quantity math, where new_quantity = current_quantity + intake_weight.

Sources: tests/data-processing-vitest.test.ts:17-100, tests/inventory-intake-processing.unit.test.ts:15-50, test-inventory-intake.sh:58-75

Integration and E2E Testing

Integration tests use Playwright to simulate user interactions and verify the full stack's response.

UI to Backend Verification

Tests in tests/event-desk-integration.spec.ts mock Supabase client responses to verify that the UI correctly displays metrics and handles API failures gracefully. Key scenarios include:

• Metric Card Loading: Verifying that cards for "Today's Sales", "Average Sale", and "Inventory Alerts" render with correct data.
• Real-time Updates: Simulating data changes and verifying the UI reflects updated totals (e.g., sales increasing after a reload).
• Error Handling: Ensuring the page remains functional even if the sales or inventory API returns a 500 error.

Sources: tests/event-desk-integration.spec.ts:1-250

Security and Permission Validation

Automated tests enforce server-side route protection and RBAC. These tests verify that users with lower roles (e.g., Cashier) cannot perform administrative actions even if they attempt to bypass the UI.

Database Testing

A dedicated Bash-based test suite validates the integrity of the PostgreSQL schema and custom SQL functions.

Schema Integrity Tests

1. Table Existence: Confirms inventory_intakes, cost_history, and inventory_log tables exist.
2. Column Validation: Ensures the metadata column is present in the inventory_log for auditing.
3. SQL Function Tests: Verifies that custom functions like is_manager(uuid, uuid) and get_avg_cost_per_gram(uuid, int) are present and callable in the database.

Sources: test-inventory-intake.sh:30-55

Pre-Release and Pre-Commit Checklists

Before code is merged or deployed, it must satisfy strict compliance and quality gates.

• Pre-Commit: Includes checks for linting, type-checking (TSC), banned direct imports (e.g., direct supabase or clerk calls), and ensuring no secrets are committed.
• Pre-Release: Focuses on versioning, changelog updates, DB migrations, and tenant isolation (verifying User A cannot access User B's data).

Sources: CHECKLIST_PRECOMMIT.md:1-12, CHECKLIST_PRERELEASE.md:1-15

Summary of Test Coverage

Category	Key Files	Purpose
Inventory	tests/inventory-intake-processing.unit.test.ts	Accuracy of stock and cost additions.
Sales	tests/event-desk-data-processing.unit.test.ts	Accuracy of dashboard analytics.
Security	testsprite_tests/TC012...py	Server-side enforcement of RBAC.
Deployment	test-inventory-intake.sh	Build and Schema validation.

Sources: tests/data-processing-vitest.test.ts:440-480, test-inventory-intake.sh:100-110

Testing in DRX CRM is a continuous process that ensures mathematical precision for inventory and financial data while strictly enforcing privacy through server-side permission validation. This strategy mitigates risks associated with manual data entry and multi-tenant data leaks.