Testing & CI Checks

Relevant source files

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

• package.json
• CONTRIBUTING.md
• AGENTS.md
• src/lib/graphql/tests/client.test.ts
• src/lib/tests/project-table-dom.test.ts
• README.md

Testing and Continuous Integration (CI) checks in the Refined GitHub Projects repository are designed to ensure code stability, technical accuracy, and adherence to critical safety rules regarding GitHub API interactions. The project utilizes a modern TypeScript-based stack and enforces strict validation through automated scripts and type checking.

While the project emphasizes that a full test framework is not the primary validator for all modules, it maintains a suite of unit tests for core logic—specifically GraphQL client interactions and DOM manipulation. CI validation primarily relies on TypeScript's strict mode and linting to maintain project integrity.

Sources: AGENTS.md:16-17, README.md:38-40

Core Validation Infrastructure

The project uses pnpm as the primary package manager and task runner for all testing and validation scripts. Validation is categorized into three main pillars: Static Analysis (Linting/Formatting), Type Checking, and Unit Testing.

Validation Scripts

The following scripts in package.json define the CI and testing entry points:

Script	Command	Purpose
typecheck	tsc --noEmit	Validates TypeScript types across the project without generating output files.
lint	eslint src/	Performs static analysis to find problematic patterns in the source code.
test	vitest run	Executes the unit test suite once.
test:coverage	vitest run --coverage	Generates code coverage reports using the V8 provider.
format:check	prettier --check 'src/**/*.{ts,tsx}'	Verifies that all files adhere to the project's formatting rules.

Sources: package.json:13-33, AGENTS.md:10-14

Unit Testing Architecture

Unit testing is powered by Vitest, utilizing happy-dom for DOM simulation and @vitest/coverage-v8 for coverage reporting. The tests focus on isolated logic within the lib directory, particularly GraphQL client error handling and project-specific DOM utility functions.

Testing Logic Flow

The testing process involves mocking external dependencies (such as browser storage and global fetch) to verify internal logic branches.

GraphQL Client Validation

Tests in src/lib/graphql/__tests__/client.test.ts ensure that the GqlError class correctly captures HTTP status codes and Retry-After headers, which is critical for the project's rate-limiting logic. The suite verifies that:

• Successful queries return expected data nodes.
• HTTP errors (403, 429) throw a GqlError with appropriate metadata.
• GraphQL-specific errors (returned in the 200 OK body) are correctly parsed and thrown.
• Required headers like Authorization and GitHub-Feature-Request are present in outgoing requests.

Sources: src/lib/graphql/tests/client.test.ts:25-132, package.json:79-84

DOM Utility Validation

Tests in src/lib/__tests__/project-table-dom.test.ts validate the extension's ability to interact with GitHub's UI. This includes:

• ID Extraction: Verifying extractItemId correctly parses data-hovercard-subject-tag or issue links.
• State Management: Checking isEditableTarget to prevent the extension from intercepting keyboard shortcuts when a user is typing in an input, textarea, or contenteditable element.

Sources: src/lib/tests/project-table-dom.test.ts:13-41, src/lib/tests/project-table-dom.test.ts:98-131

Critical CI Safety Rules

The project enforces "Non-negotiable" rules during development and CI to prevent users' Personal Access Tokens (PATs) from being banned by GitHub. These rules are manually reviewed and programmatically checked via type safety.

• Sequential Mutations: Promise.all() is strictly forbidden for GraphQL mutations. All writes must run through the sequential queue found in lib/queue.ts.
• Rate-Limit Safety: A 1-second delay (sleep(1000)) is required between mutations to avoid 403 Abuse alerts.
• Architecture Isolation: API calls must never originate from Content Scripts; they must be sent via messages to the Background Service Worker.

Coverage and Maintenance

The repository includes a mechanism to track testing progress through a coverage badge, which is updated via a custom script (scripts/update-coverage-badge.mjs). As of the current version, the coverage stands at approximately 13.98%.

CI Tooling

• Husky & Lint-staged: Automatically runs eslint --fix and prettier --write on staged files before commits.
• TypeScript Strict Mode: Enforced to minimize the use of any and ensure type safety across the messaging and storage layers.

Sources: package.json:32-40, README.md:28, CONTRIBUTING.md:26-27

Summary

Testing and CI checks in this project prioritize technical safety and type integrity over broad test coverage. By enforcing sequential execution of API calls and utilizing Vitest for critical utility validation, the CI process ensures that the extension remains compatible with GitHub's rate-limiting policies while maintaining a stable UI for bulk operations.