Testing Strategy

Introduction

The testing strategy for MessageJS is currently in an early development phase, with foundational elements in place and a comprehensive testing framework planned for the future. The current approach combines manual testing features, mock implementations for development, and a structured approach for future automated testing. The monorepo is configured with a top-level test script, and the project structure includes dedicated tests/ directories, indicating a clear path towards a robust testing culture.

As stated in the project's main README.md, a "Testing framework" is a planned item, while core infrastructure and type systems are complete. This document outlines the testing mechanisms and philosophies that are currently evident in the codebase.

Sources: README.md:73, mono-repo.md:4

Monorepo Test Execution

The project is set up as a monorepo and utilizes npm workspaces to manage its packages. A root-level test script is defined to delegate test execution to each individual workspace. This allows each package (core, client, etc.) to have its own specific testing setup and dependencies while being runnable from a single command.

// package.json:10
"scripts": {
  "test": "npm run test --workspaces",
},

This structure suggests that unit, integration, and other forms of automated tests are intended to be co-located with the package they are testing.

Sources: package.json:10-12

Backend API Testing

The backend testing strategy currently relies on mock implementations and a dedicated API endpoint for connector validation. The architecture is designed to accommodate future integration testing.

Mock Implementations

During the early development phase, key parts of the API, such as the authentication middleware and message controller, use in-memory mock implementations. This allows for rapid development and testing of the API's contract and flow without requiring a full database or external service integration.

For example, the validateApiKey middleware uses a hardcoded mock API key to simulate successful authentication and attaches mock project data to the request object.

// packages/core/src/api/middleware/authMiddleware.ts:43-45
const MOCK_API_KEY = 'pk_live_a1b2c3d4e5f6g7h8i9j0';
const MOCK_PROJECT_ID = 'proj_123456789';
const MOCK_API_KEY_ID = 'key_abcdefgh';

Similarly, the sendMessage controller simulates the message queuing process and returns a successful 202 Accepted response with a mock message ID, as per the system design.

Sources: packages/core/src/api/middleware/authMiddleware.ts:43-52, packages/core/src/api/controllers/messageController.ts:47-54

Planned Integration Testing

The main server entry point (packages/core/src/index.ts) exports the Express app instance. This is explicitly noted as a good practice to allow the application to be imported for integration testing, signaling the intention to write tests that can run against the full API without needing to start a live server.

Sources: packages/core/src/index.ts:43-46

Planned Input Validation

The messageController includes a TODO comment indicating a plan to implement robust input validation using a library like Zod. This is a critical part of the testing and security strategy to ensure that all incoming API requests conform to the expected schema before being processed.

Sources: packages/core/src/api/controllers/messageController.ts:23

Connector Validation

A key user-facing feature of the testing strategy is the ability to validate connector credentials directly from the MessageJS dashboard. This is supported by a dedicated API endpoint and a standardized connector interface.

Connector Test Endpoint

The API provides an endpoint specifically for testing the validity of a connector's configuration. This allows users to confirm that their credentials (e.g., API tokens, phone number IDs) are correct before attempting to send messages.

• Endpoint: POST /api/v1/projects/:projectId/connectors/:id/test
• Authorization: Bearer <jwt_token>
• Success Response (200 OK):

  {
    "success": true,
    "connected": true,
    "message": "Connected to WhatsApp Cloud API"
  }
  

This flow is initiated from the dashboard, as described in the Quick Start guide, where a user can click a "Test Connection" button after adding credentials for a service like WhatsApp or Telegram.

The following diagram illustrates the connector testing flow from the user's perspective.

IConnector validate Interface

The connector validation mechanism is enforced at the architectural level through the IConnector interface. Every connector implementation must provide a validate method. This method is responsible for making a non-sending API call to the third-party service to verify credentials.

The validate method must return a ConnectorStatus object, which standardizes the result of the test.

This interface-driven approach ensures that any new connector added to the system will automatically support the "Test Connection" feature, making the system extensible and maintainable.

Sources: packages/core/src/connectors/IConnector.ts:51-67