TitanX: Skill for Claude Code

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

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

Keep each it() focused. More than 3 expect() calls in one test is a signal it is testing too much at once.