Quality Assurance

Stability and reliability are core pillars of this library. To ensure a "Rolls-Royce" developer experience, we employ a multi-layered testing strategy that covers everything from internal logic to live API responses.

Testing Layers

1. Unit Testing

We use Vitest to test the internal logic of the library in isolation. This includes:

• Throttling Logic: Verifying that the client correctly queues requests to stay within the 50 req / 5s limit.
• Error Handling: Ensuring that various API error codes (404, rate limits, schema errors) are mapped to the correct TypeScript exceptions.
• Search Builder: Testing every permutation of the fluent builder to ensure it produces valid query strings.

2. Type-Level Testing

Our API response types aren't just documentation; they are strictly enforced. We use vitest --typecheck to ensure that:

• Method signatures always match the expected input.
• The data returned by the client exactly satisfies the TypeScript interfaces defined in our core types.

3. Runtime Validation (Live Snapshots)

One of the unique features of this library is its Live Snapshot Testing. We maintain a test suite that:

1. Calls the actual Deezer API.
2. Extracts the "shape" of the response.
3. Compares that shape against a stored snapshot.

If Deezer updates their API (adding or removing fields), our tests will fail immediately, alerting the maintainers that a type update is required.

4. Automated Documentation Sync

To prevent documentation from becoming "stale," we use a custom synchronization script. This ensures that:

• The Schemas shown in the documentation are pulled directly from the actual TypeScript interfaces.
• The Example Responses are real-world data fetched from the live API.

Code Coverage

We maintain a strict 100% Code Coverage policy for all core logic. Every logical branch, fallback, and error handler is verified by at least one test case.

Continuous Integration (CI)

Every pull request and commit undergoes a rigorous automated pipeline:

• Linting: Ensuring consistent code style and best practices.
• Build: Verifying that the dual ESM/CJS build completes without errors.
• Tests: Running the full unit and type-test suite.
• Audit: Scanning for security vulnerabilities in dependencies.

Supply Chain Security

• Zero Runtime Dependencies: The package has 0 external dependencies at runtime, eliminating risk from nested package vulnerabilities.
• Provenance: Published versions are cryptographically linked to the GitHub source code repository using npm provenance.