Testing Suites & QA Environment
Relevant source files
The following files were used as context for generating this wiki page:
The TAMV Atlas testing and QA environment is governed by the QC-TAMV-01 Constitutional Quality Framework. This framework establishes non-negotiable technical invariants and ties architectural principles to executable mechanisms such as linting, unit testing, and static analysis. The environment ensures that every technical artifact is traceable, deterministic, and isolated across layers (pages, modules, and domains).
The QA strategy is divided into automated CI/CD pipelines (MD-X5), architectural validation scripts, and runtime health checks. While the project currently reports a 52% progress in automated QA quality, it maintains a rigorous standard for critical operations including identity verification, signature cycles, and structural integrity.
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:14-18, README.md:126
1. QC-TAMV-01 Architectural Validation
The core of the QA environment is a set of "Constitutional Laws" (L1–L9) that enforce architectural purity. These rules are validated through automated scripts and ESLint plugins to prevent coupling and ensure structural determinism.
Constitutional Laws (L1–L9)
| Law | Name | Invariant Requirement |
|---|---|---|
| L1 | Unique Root | createRoot must only exist in src/main.tsx. |
| L2 | Unique Router | BrowserRouter is restricted to src/App.tsx. |
| L3 | Unique Design | Layout.tsx must be mounted exactly once in App.tsx. |
| L4 | Route-Page Map | Every file in src/pages/* must correspond to a single route. |
| L6 | Independent Modules | src/modules/* cannot import react-router-dom or pages. |
| L8 | Separation of Concerns | No layer may assume the responsibilities of another. |
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:24-38
Automated Architecture Checker
A specialized script, check-architecture.ts, implements the QC-TAMV-01 v1.1 standards by analyzing the dependency graph. It scans source files to detect violations such as page-to-page imports or unauthorized use of routing components outside the application root.
The architecture checker provides a detailed JSON report including the count of pages, modules, domains, and specific violation messages.
Sources: federation/tamv-digital-nexus/scripts/check-architecture.ts:182-273
2. Pipeline MD-X5 (Deca-V)
The MD-X5 pipeline consists of 10 cycles that are mandatory for any Pull Request to the main or release branches. This pipeline covers the full spectrum of QA, from static analysis to post-deployment verification.
Pipeline Cycles
- npm run lint: ESLint using
eslint-plugin-tamvin error mode. - npm run typecheck: TypeScript validation without emission.
- npm run test: Unit testing via Vitest.
- npm run test:e2e: Integration testing via Playwright.
- Contract-test: Verification of module inter-contracts.
- Security-scan: DEKATEOTL security gates.
- SBOM/check-licenses: Software Bill of Materials and license audits.
- Build + Artifact Signing: Build execution and cryptographic signing.
- Deploy Canary: Gradual deployment.
- Post-deploy verification: Automatic verification and rollback gates.
Sources: src/pages/wiki/implementacion/CicdPipelines.tsx:50-63
3. Backend API & Integration Testing
The backend testing suite focuses on service health, security posture, and the integrity of cryptographic cycles. Tests are implemented using the native node:test runner.
Critical Test Domains
- Post-Quantum Security: Verification of the
v1/security/postureendpoint, ensuring theantifragilityScoreand PID triangulation controls are functional. - Signature Cycles: A complete cycle of signing a payload and verifying the signature to ensure cryptographic non-repudiation.
- PID Provider Status: Validating reachable status for external providers like ORCID, Zenodo, and ISNI.
- Omni-Kernel Registration: Testing the registration of users and processing of requests within the federated kernel.
Sources: backend/tests/api.test.js:31-90
4. Runtime Health & Fusion Monitoring
The tamv-fusion-core performs runtime health checks across critical infrastructure, including route availability and database integrity.
Health Monitoring Parameters
The system monitors a set of critical routes and database tables, reporting status codes and counts.
| Monitoring Area | Targets |
|---|---|
| Critical Routes | /, /dashboard, /isabella, /governance, /bookpi, /auth |
| Critical Tables | profiles, posts, msr_events, tcep_wallets, user_roles |
| MSR Registry | Every fusion cycle generates an immutable entry with a SHA-256 evidence hash. |
Sources: [federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:37-65], federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:98-112
5. QA Metrics and Readiness
The project tracks QA progress through a "Research Dossier" and readiness percentages. As of the current audit, the QA environment is in a state of "pre-production advanced."
- Readiness Level: 52% (Quality/QA automated).
- Verification Status: Many claims (e.g., IA Isabella governance) are currently "not_verified" and require auditable demos or public repositories.
- Success Metrics: The goal is 100% coverage of QC-TAMV-01 rules and a P95 latency of less than 4 seconds for services.
Sources: README.md:126, backend/src/researchDossier.js:25-35, src/pages/wiki/implementacion/CicdPipelines.tsx:100-112
The Testing Suites and QA Environment in TAMV Atlas represent a structured transition from a documented vision to an executable, verifiable infrastructure. By combining constitutional architectural checks with standard CI/CD pipelines and runtime health monitoring, the project ensures that its "Humanism in Code" principles are backed by technical evidence.