frontend-testing
Frontend Testing
Start by writing tests that validate acceptance criteria. Then add implementation tests where they provide value.
Core Principle
"The more your tests resemble the way your software is used, the more confidence they can give you." — Kent C. Dodds
This principle guides testing decisions, but isn't the whole picture:
- Acceptance criteria tests verify the system does what users/stakeholders need. These should be stable across refactors.
- Implementation tests verify the pieces are robust — edge cases, error handling, complex logic. These may change when you refactor.
Both have value. The anti-pattern to avoid is tests that only mirror implementation without validating meaningful behavior.
When to Load References
Load reference files based on test type:
More from schalkneethling/webdev-agent-skills
frontend-security
Audit frontend codebases for security vulnerabilities and bad practices. Use when performing security reviews, auditing code for XSS/CSRF/DOM vulnerabilities, checking Content Security Policy configurations, validating input handling, reviewing file upload security, or examining Node.js/NPM dependencies. Target frameworks include web platform (vanilla HTML/CSS/JS), React, Astro, Twig templates, Node.js, and Bun. Based on OWASP security guidelines.
203semantic-html
Write well-considered semantic HTML that serves all users. Use when creating components, page structures, or reviewing markup. Emphasizes native HTML elements over ARIA. Treats proper document structure and accessibility as foundations rather than afterthoughts.
171css-coder
CSS authoring guidance emphasizing web standards, accessibility, and performance. Use when writing, reviewing, or refactoring CSS. Provides patterns, snippets, and conventions that prioritize native CSS over frameworks, semantic structure, and maintainable code. Refer to references/patterns.md for specific patterns and snippets.
41css-tokens
Provides foundational CSS design tokens (custom properties) for typography, spacing, colors, borders, z-index, and transitions. Use when setting up a base token system for a web project.
17component-scaffolding
Generate Drupal/Twig component skeletons with web components and Miyagi validation. Use when user requests to create, scaffold, or add a new component at a specific path (e.g., "add component skeleton at patterns/share-button"), or when creating component files including Twig templates, CSS, JavaScript web components, JSON schemas, or mock data files.
14component-usage-analysis
Analyse component dependencies and usage patterns in a Drupal/Twig component library. Use when user asks to find where a component is used, check if a component can be safely removed, audit component dependencies, find components using specific properties, or analyse impact of refactoring a component.
13