Skills

Testing

Testing workflow and quality standards for writing and running tests.

Install

npx skills add iOfficeAI/AionUi --skill testing -g -a claude-code -y
Repository
iOfficeAI/AionUi34k
Category
Testing
Updated
12d ago
License
Apache-2.0
Context cost
Lightabout 1,123 tokens
Runs scripts
No, instructions only

What it does

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.

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

EnvironmentWhenFile naming
node (default)Main process, utilities, services*.test.ts
jsdomDOM/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

// 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

Read the whole SKILL.md on GitHub

More in Testing