testing

Document Tale's testing conventions across Vitest, Testing Library, vitest-axe, and Playwright.

20|5|Updated Nov 30, 2025
One-click install
npx skills add https://github.com/tale-project/tale --skill testing-tale-project
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing
Source: https://github.com/tale-project/tale/tree/main/.claude/skills/testing
Command: npx skills add https://github.com/tale-project/tale --skill testing-tale-project

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

How testing works in the Tale monorepo — Vitest unit/component (co-located), Testing Library, vitest-axe a11y blocks, Playwright e2e, the test-file layout and naming dispatcher, and the commands. Read before writing or changing a test, adding an e2e spec, debugging a flaky test, or deciding where a test file goes. Driving the real app by hand instead is browser-qa.

Core Features & Use Cases

  • Vitest for unit/component (co-located) tests
  • Testing Library for DOM
  • vitest-axe for a11y
  • Playwright for e2e
  • test-file layout and naming dispatcher
  • browser-qa for manual QA
  • Commands to run tests and verify

Quick Start

Run the repository's test suite locally to validate unit, integration, and end-to-end tests.

Frequently Asked Questions about testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure test files in a monorepo using Vitest and Playwright?▼

Test files in a monorepo should follow co-located unit/component conventions for Vitest and dedicated layouts for Playwright e2e specs. The testing workflow uses a naming dispatcher to standardize test-file layout and enforce repeatable directory structures across the repository.

How do I run accessibility checks in Vitest for component tests?▼

Accessibility checks in Vitest are handled using vitest-axe blocks within Testing Library component tests. This integrates a11y validation directly into the co-located unit and DOM testing workflow to ensure components meet accessibility standards.

What's the best way to organize end-to-end testing with Playwright in a monorepo?▼

Organizing end-to-end testing with Playwright involves following documented conventions for e2e scenarios and test-file layout. The testing workflow standardizes guidance for adding e2e specs and ensures frontmatter metadata is enforced across the repository.

When should I use manual browser QA instead of automated testing?▼

Manual browser QA should be used when driving the real application by hand instead of running automated test suites. It serves as a separate workflow from the automated Vitest, Testing Library, and Playwright tests defined in the testing conventions.

Does the testing workflow support Testing Library for DOM testing?▼

Yes, the testing workflow supports Testing Library specifically for DOM testing. It standardizes conventions across Vitest, Testing Library, and Playwright to provide a repeatable workflow for unit, component, and e2e tests.

Why does my test file layout require frontmatter metadata?▼

Test file layouts require frontmatter metadata to enforce standardized testing guidance and maintain a repeatable workflow across the monorepo. This convention ensures consistency when adding or modifying Vitest and Playwright test files.