Testing Strategy

Relevant source files

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

• scripts/test-all-modules.js
• scripts/test-chat-module.js
• scripts/test-requests-crud.js
• scripts/test-storage-crud.js
• REPORTE-EJECUCION-PRUEBAS.md
• REPORTE_CHAT_MODULE.md
• REPORTE_FINAL_VALIDACION.md
• TEST_REPORT.md

The testing strategy for the ElmecV2 project is centered on automated backend validation using Node.js scripts that interact directly with the Supabase backend. This approach ensures the integrity of the database schema, Row Level Security (RLS) policies, and API logic exposed via the Supabase client library. The strategy clearly delineates between backend tests, which are automated, and frontend/UI tests, which are documented as "omitted" and recommended for manual or separate E2E testing frameworks.

The core of the strategy involves a suite of test scripts located in the scripts/ directory. These scripts are executed via the command line and produce detailed reports in the console and as Markdown files. This allows for continuous verification of backend functionality, independent of the client application.

Sources: REPORTE-EJECUCION-PRUEBAS.md, scripts/test-all-modules.js

Test Automation Framework

The project utilizes a lightweight, custom testing framework built with Node.js. It does not rely on external testing libraries like Jest or Mocha, but instead uses a set of helper functions for assertions and reporting.

• Technology Stack: Node.js, @supabase/supabase-js for backend interaction, and dotenv for environment variable management.
• Supabase Client: Tests use the Supabase client to perform operations. Some scripts use the SUPABASE_SERVICE_ROLE_KEY to bypass RLS for setup and cleanup, while others use the public anonKey to test security policies.
• Test Structure: Each test script is self-contained and can be run independently. They typically include setup, execution of test cases for different modules or CRUD operations, and a cleanup phase to remove test data.
• Reporting: Test results are logged to the console with color-coding for immediate feedback. Detailed Markdown reports are also generated, summarizing execution metrics, passed/failed tests, and any fixes applied.

Sources: scripts/test-requests-crud.js:9-15, scripts/test-storage-crud.js:15-19, REPORTE-EJECUCION-PRUEBAS.md

Key Test Scripts

Script	Purpose
scripts/test-all-modules.js	An integration-style script that runs a battery of tests across all major backend modules.
scripts/test-requests-crud.js	A focused CRUD test suite for the requests table and its related functionality.
scripts/test-chat-module.js	A comprehensive test suite for the chat functionality, including rooms, messages, and realtime features.
scripts/test-storage-crud.js	A dedicated script for validating all CRUD operations on the Supabase Storage bucket request-files.

Sources: scripts/test-all-modules.js, scripts/test-requests-crud.js, scripts/test-chat-module.js, scripts/test-storage-crud.js

Test Suites

Comprehensive Module Testing

The test-all-modules.js script serves as the primary integration test, validating the core functionality of multiple modules in a single run.

The script executes tests sequentially for the following modules:

1. Authentication
2. Requests
3. Chat
4. Notifications
5. Directory

Tests that depend on frontend logic or UI interaction (e.g., biometrics, file uploads from UI, push notifications) are explicitly skipped, with the reason logged in the report.

Sources: scripts/test-all-modules.js:688-694, REPORTE-EJECUCION-PRUEBAS.md

The following diagram illustrates the execution flow of the main test script.

Requests Module CRUD Testing

The scripts/test-requests-crud.js script performs a complete lifecycle test of the requests entity. It validates all four CRUD operations and related business logic.

The test sequence is as follows:

1. Setup: Fetches a test customer and agent user from the users table.
2. Create: Inserts new requests, one simple and one with simulated file attachments.
3. Read: Lists all requests for the test user and fetches a specific request by ID, verifying joins with the users table.
4. Update: Modifies the estatus, prioridad, feedback, and rating of the test requests.
5. Delete: Removes all created test data, including files from Storage, to ensure atomicity and a clean state.

Sources: scripts/test-requests-crud.js

This sequence diagram shows the interactions between the test script and Supabase for the Requests CRUD test.

Chat Module Testing

The scripts/test-chat-module.js script is a detailed suite that validates the complex functionalities of the real-time chat system. It covers the creation of chat rooms, sending various message types, and verifying real-time subscriptions.

Key validated features include:

• CRUD for chat_rooms.
• Sending messages of type text, image, file, and audio.
• Replying to messages (reply_to field).
• Editing and soft-deleting messages.
• Real-time message reception via Supabase subscriptions.
• Presence tracking for "typing" indicators.

The tests also identified discrepancies between the application code's expectations and the actual database schema, such as missing columns (reply_to, file_name, edited_at), which were documented in the test reports.

Sources: scripts/test-chat-module.js, REPORTE_CHAT_MODULE.md

Storage Module CRUD Testing

The scripts/test-storage-crud.js script is dedicated to verifying the functionality of Supabase Storage, specifically the request-files bucket.

The test flow includes:

1. Create: Uploading files of different types (txt, json, csv).
2. Read: Listing files in a folder, getting a file's public URL, and downloading a file to verify its content.
3. Update: Overwriting an existing file and moving/renaming a file.
4. Delete: Removing individual and multiple files.
5. Cleanup: Ensuring the test folder is empty after the run.

Sources: scripts/test-storage-crud.js

Test Execution and Reporting

Test execution is performed by running the Node.js scripts. The output provides a real-time log of passed, failed, and skipped tests.

Upon completion, a summary is generated, and detailed Markdown reports like REPORTE-EJECUCION-PRUEBAS.md are created to formalize the results. These reports are a critical part of the strategy, providing a persistent and shareable artifact of the test run.

Test Metrics

The reports include a high-level summary of test metrics.

Métrica	Valor
Total de Casos Ejecutados	120 / 213
Pruebas Pasadas	26
Pruebas Fallidas	0
Pruebas Omitidas	94
Tasa de Éxito	100% (26/26)
Duración Total	2.94 segundos

Sources: REPORTE-EJECUCION-PRUEBAS.md

Analysis of Omitted Tests

A significant portion of the test cases are marked as "Omitted". This is a deliberate design choice to separate backend and frontend testing.

Razón de Omisión	Cantidad	Porcentaje
Pruebas de UI/Frontend	81	86.2%
Requieren roles específicos	5	5.3%
Features no implementadas	4	4.3%
Requieren espera prolongada	2	2.1%
Evitar crear datos de prueba	2	2.1%

Sources: REPORTE-EJECUCION-PRUEBAS.md

The reports recommend using a framework like Detox or Appium to cover the 94 omitted UI tests.

Sources: REPORTE-EJECUCION-PRUEBAS.md

Coverage and Scope

The automated testing strategy is strictly focused on the backend. It validates the application's data layer and business logic as implemented in the Supabase database and APIs. It does not cover the React Native frontend.

This diagram shows the clear separation of testing responsibilities.

Conclusion

The testing strategy for ElmecV2 is robust and pragmatic, focusing automated efforts on validating the critical backend infrastructure provided by Supabase. By using self-contained Node.js scripts, the project ensures that its data models, business rules, and security policies function correctly, independent of the client application. The clear documentation of scope and the generation of detailed reports make this a mature and effective approach for maintaining backend quality. The strategy correctly identifies the need for a separate E2E testing effort for the frontend, ensuring complete test coverage for the entire application stack.

Sources: REPORTE-EJECUCION-PRUEBAS.md, VALIDACION-COMPLETA.md