# Testing

Testing workflow and quality standards for writing and running tests.

- Repository: https://github.com/iOfficeAI/AionUi (33977 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-10-23
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add iOfficeAI/AionUi --skill testing -g -a claude-code -y`
Codex: `npx skills add iOfficeAI/AionUi --skill testing -g -a codex -y`
Cursor: `npx skills add iOfficeAI/AionUi --skill testing -g -a cursor -y`
Gemini CLI: `npx skills add iOfficeAI/AionUi --skill testing -g -a gemini-cli -y`

## Description

Testing workflow and quality standards for writing and running tests. Use when: (1) Writing new tests, (2) Adding a new feature that needs tests, (3) Modifying logic that has existing tests, (4) Before claiming a task is complete.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Testing Skill

Standards and workflow for writing and running tests. Every feature must be tested.

**Announce at start:** "I'm using testing skill to ensure proper test coverage."

## Trigger Conditions

- Writing new tests for a feature or bug fix
- Adding a new feature (must include tests)
- Modifying logic that has existing tests (must update them)
- Before claiming work is complete
- Before committing code

## Framework

**Vitest 4**, configured in `vitest.config.ts`.

## Test Structure

```
tests/
├── unit/          # Individual functions, utilities, components
├── integration/   # IPC, database, service interactions
├── regression/    # Regression test cases
└── e2e/           # End-to-end tests (Playwright, playwright.config.ts)
```

## Two Test Environments

| Environment      | When                              | File naming     |
| ---------------- | --------------------------------- | --------------- |
| `node` (default) | Main process, utilities, services | `*.test.ts`     |
| `jsdom`          | DOM/browser-dependent code        | `*.dom.test.ts` |

## Workflow

### Step 1: Identify What to Test

Before writing tests, list the **riskiest scenarios** first:

- What happens when the dependency returns `undefined` / throws?
- What happens at boundaries (empty list, max retries, past timestamp)?
- What is most likely to break in production?

### Step 2: Write Tests

Follow these quality rules:

**1. Describe behavior, not code structure**

```typescript
// Wrong, describes implementation
it('should call repo.getConversation', ...)

// Correct, describes behavior
it('should return cached task without hitting repo on second call', ...)
it('should reject with error when conversation does not exist', ...)
```

**2. Every describe block must cover at least one failure path**

Happy-path-only tests leave the most dangerous code untested.

**3. One behavior per test**

The rest: https://github.com/iOfficeAI/AionUi/blob/HEAD/.claude/skills/testing/SKILL.md