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.