Testing Strategy

The testing strategy for wrelik-kit is designed to ensure the reliability of its adapter-first architecture. As a monorepo containing vendor-agnostic adapters and shared utilities, the project emphasizes minimal surface area and explicit boundaries. Testing is integrated into the core development workflow, requiring all new packages to include "minimal tests" as part of the implementation process.

Sources: CONTRIBUTING.md:5, README.md:10-18

Test Execution and Orchestration

Testing is managed through a centralized monorepo task runner, ensuring consistency across various packages such as @wrelik/auth, @wrelik/db, and @wrelik/storage.

Turborepo Integration

The project uses Turborepo to orchestrate test execution. The test task is configured with a dependency on the build task, ensuring that code is compiled before tests are run. This configuration also tracks coverage outputs and specifies input file patterns to optimize caching.

The diagram shows the task dependency where the build process must complete before the testing suite initiates.
Sources: turbo.json:11-15, package.json:12

Package-Level Testing

Individual packages utilize vitest as the primary test runner. Each package's package.json defines a test script that executes Vitest in a one-time run mode, often configured to pass even if no tests are found to facilitate the addition of new, initially empty modules.

Sources: packages/auth/package.json:16-18, packages/jobs/package.json:11-13, packages/config/package.json:12-14

Unit Testing Patterns

Unit tests in the repository focus on validating the logic of adapters and utility functions. A primary example is found in the @wrelik/auth package, which tests authentication session handling and parsing.

Auth Module Example

Testing for the auth package includes verifying error handling (e.g., throwing AuthRequiredError when a session is missing a user ID) and validating the transformation of vendor-specific data (Clerk) into the internal wrelik-kit format.

The sequence diagram illustrates how the Auth adapter validates session presence and standardizes vendor data.
Sources: packages/auth/src/index.test.ts:1-30

Quality Assurance and CI/CD

The testing strategy is part of a broader "infrastructure-first" philosophy. The repository enforces strict boundaries through automated tooling and versioning workflows.

Tooling and Standards

• Static Analysis: Shared configurations for ESLint (@wrelik/eslint-config) and TypeScript (@wrelik/tsconfig) are applied across all packages to enforce coding standards.
• Dependency Constraints: ESLint rules are used to prevent direct vendor SDK imports in applications, forcing developers to use the tested adapters provided by this kit.
• Versioning: All changes require a "changeset" to be documented. The release lifecycle includes a CI-driven "Version PR" that is only triggered after code passes the main branch integration.

Sources: CONTRIBUTING.md:15-32, packages/eslint-config/index.js:14-48, README.md:120-125

Development Workflow

Developers are encouraged to follow a specific lifecycle to maintain the integrity of the kit:

1. Initialize package with required dev dependencies (tsconfig, eslint-config).
2. Implement standardized logic.
3. Add unit tests using the vitest framework.
4. Run the global test command pnpm test via Turbo.

Sources: CONTRIBUTING.md:1-5, package.json:12

Summary

The wrelik-kit testing strategy centers on Vitest for unit testing and Turborepo for workspace-wide orchestration. By enforcing "minimal tests" for every package and utilizing strict linting rules to prevent vendor lock-in, the project ensures that its core adapters remain reliable and easy to replace.