菜单
Automatically activated when user asks about test quality, code coverage, test reliability, test maintainability, or wants to analyze their test suite. Provides framework-agnostic test quality analysis and improvement recommendations. Does NOT provide framework-specific patterns - use jest-testing or playwright-testing for those.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Expert at creating Claude Code event hooks for automation and policy enforcement. Auto-invokes when creating/updating hooks, modifying hooks.json, designing event-driven automation, or writing hook configurations.
Expert at creating and modifying Claude Code agents. Auto-invokes when creating/updating agents, modifying agent frontmatter (model, tools, description), designing agent architecture, or writing to */agents/*.md files.
Expert at creating and modifying Claude Code slash commands. Auto-invokes when creating/updating commands, modifying command frontmatter (model, allowed-tools, argument-hint), designing workflows, or writing to */commands/*.md files.
Expert at integrating MCP servers into Claude Code plugins. Auto-invokes when configuring MCP servers (stdio/SSE/HTTP/WebSocket), writing .mcp.json files, or adding external tool integrations.
Expert at creating Claude Code plugins that bundle agents, skills, commands, and hooks. Auto-invokes when creating/structuring plugins, writing plugin.json manifests, or bundling components into packages.
Expert at performing task X automatically. Auto-invokes when the user wants to do Y, needs help with Z, or encounters situation W.
| name | analyzing-test-quality |
| description | Automatically activated when user asks about test quality, code coverage, test reliability, test maintainability, or wants to analyze their test suite. Provides framework-agnostic test quality analysis and improvement recommendations. Does NOT provide framework-specific patterns - use jest-testing or playwright-testing for those. |
| version | 1.1.0 |
| allowed-tools | Read, Grep, Glob, Bash |
| capabilities | ["quality-metrics","anti-pattern-detection","coverage-analysis","mutation-testing","test-pyramid-balance","reliability-assessment","maintainability-scoring","flakiness-detection"] |
You are an expert in test quality analysis with deep knowledge of testing principles, patterns, and metrics that apply across all testing frameworks.
Claude should automatically invoke this skill when:
Use {baseDir} to reference files in this skill directory:
{baseDir}/scripts/{baseDir}/references/{baseDir}/assets/This skill includes ready-to-use resources in {baseDir}:
Tests accurately verify intended behavior:
Tests are easy to understand:
Tests are easy to modify:
Tests produce consistent results:
Tests run efficiently:
// BAD: Shared mutable state
let count = 0;
beforeEach(() => count++);
// GOOD: Reset in setup
let count: number;
beforeEach(() => { count = 0; });
Mocking too much hides bugs and makes tests brittle.
// BAD: Mock everything - test only verifies mocks
// Jest
jest.mock('./dep1');
jest.mock('./dep2');
jest.mock('./dep3');
// Vitest
vi.mock('./dep1');
vi.mock('./dep2');
vi.mock('./dep3');
// GOOD: Mock boundaries only
// Mock external services, keep internal logic real
mock('./api'); // External service only
// Test actual business logic
// BAD: Timing dependent
await delay(100);
expect(element).toBeVisible();
// GOOD: Wait for condition
// Testing Library
await waitFor(() => expect(element).toBeVisible());
// Playwright
await expect(element).toBeVisible();
// BAD: Hidden dependencies
test('should process', () => {
const result = process(); // Uses global data
expect(result).toBe(42);
});
// GOOD: Explicit setup
test('should process input', () => {
const input = createInput({ value: 21 });
const result = process(input);
expect(result).toBe(42);
});
// BAD: Multiple unrelated assertions
test('should work', () => {
expect(user.name).toBe('John');
expect(items.length).toBe(3);
expect(total).toBe(100);
});
// GOOD: Focused assertions
test('should set user name', () => {
expect(user.name).toBe('John');
});
test('should have correct item count', () => {
expect(items).toHaveLength(3);
});
Mutation testing validates test effectiveness by modifying code and checking if tests catch the changes.
# Install Stryker
npm install -D @stryker-mutator/core
# For specific frameworks
npm install -D @stryker-mutator/jest-runner # Jest
npm install -D @stryker-mutator/vitest-runner # Vitest
npm install -D @stryker-mutator/mocha-runner # Mocha
# Initialize configuration
npx stryker init
// stryker.conf.js
module.exports = {
packageManager: 'npm',
reporters: ['html', 'clear-text', 'progress'],
testRunner: 'jest',
coverageAnalysis: 'perTest',
// What to mutate
mutate: [
'src/**/*.ts',
'!src/**/*.test.ts',
'!src/**/*.spec.ts',
],
// Mutation types to use
mutator: {
excludedMutations: [
'StringLiteral', // Skip string mutations
],
},
// Thresholds
thresholds: {
high: 80,
low: 60,
break: 50, // Fail CI if below this
},
};
Mutation score: 85%
Killed: 170 | Survived: 30 | Timeout: 5 | No coverage: 10
High score (>80%): Tests are effective Medium score (60-80%): Some weak areas Low score (<60%): Tests need significant improvement
Boundary mutations: < changed to <=
// Mutation survives if tests don't check boundary
if (value < 10) { ... } // Changed to: value <= 10
Arithmetic mutations: + changed to -
// Mutation survives if result isn't precisely checked
return a + b; // Changed to: a - b
Boolean mutations: && changed to ||
// Mutation survives if both conditions aren't tested
if (a && b) { ... } // Changed to: a || b
# GitHub Actions
- name: Run mutation tests
run: npx stryker run
- name: Upload Stryker report
uses: actions/upload-artifact@v3
with:
name: stryker-report
path: reports/mutation/
// Recommended minimums
{
statements: 80,
branches: 75,
functions: 80,
lines: 80
}
Mutation testing modifies code to check if tests catch the changes:
When analyzing test quality:
Gather Metrics
Identify Patterns
Evaluate Reliability
Provide Recommendations
When analyzing coverage:
When auditing for reliability: