antd-test-review

Review Ant Design test cases for redundancy and implementation self-validation.

99.3k|54.7k|Updated Apr 24, 2015
One-click install
npx skills add https://github.com/ant-design/ant-design --skill antd-test-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: antd-test-review
Source: https://github.com/ant-design/ant-design/tree/main/.agents/skills/test-review
Command: npx skills add https://github.com/ant-design/ant-design --skill antd-test-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents low-value tests from polluting the Ant Design codebase by identifying cases that merely re-prove the implementation, lock onto internal details, or duplicate existing coverage.

Core Features & Use Cases

  • Contract Independence Check: Evaluates whether a test's expected value comes from an independent source (issue, docs, DOM semantics) or is reverse-engineered from the production code.
  • Implementation Detail Detection: Flags assertions on private helpers, internal state, specific CSS properties, and temporary class names as low-value by default.
  • Redundancy Analysis: Compares new test cases against existing mountTest, rtlTest, and behavior-focused tests to identify duplicate coverage.
  • Use Case: A contributor opens a PR adding a new test for a Tooltip component. Use this Skill to determine whether the test protects a real user-facing behavior or just re-asserts the implementation logic.

Quick Start

Review the test cases in this PR diff and tell me which ones should be deleted, rewritten, or kept.

Frequently Asked Questions about antd-test-review

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

FAQPage Schema
How do I review React component test cases for quality?

Check whether the expected value comes from an independent source like documentation, issue descriptions, or DOM semantics. If the assertion can only be derived from reading the production code, the test likely re-proves the implementation and should be flagged as low-value.

What makes a test case low value or redundant?

A test is low value when its expected output is computed from the same code path it tests, when it asserts private helpers or internal state, or when existing tests like mountTest and rtlTest already cover the same contract with similar props combinations.

Should I assert CSS properties in component tests?

CSS property assertions like toHaveStyle or toHaveClass are treated as low-value by default unless they correspond to a documented public contract. Prefer asserting on DOM structure, text content, ARIA attributes, or user-observable behavior instead.

Why is using A to prove A bad in testing?

When a test computes its expected value from the same implementation it exercises, it will always pass regardless of correctness. This creates false confidence and fails to catch regressions because the assertion and the code share the same logic.

When should I rewrite a test instead of deleting it?

Rewrite when the test intent targets a real user-facing behavior but the assertion method locks onto implementation details. Replace style or class assertions with DOM, role, or callback-based assertions that verify the same contract externally.