[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70NGPB71WEC7BF3VQSVJPWR":3,"skill-same:01M70NGPB71WEC7BF3VQSVJPWR":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M70NGPB71WEC7BF3VQSVJPWR","test-strategy-design",null,"Test pyramid strategy, test design patterns, coverage analysis, and quality gate configuration. Use when designing test strategies, improving coverage, setting up automation, or defining quality gates. Covers unit, integration, and E2E testing across frameworks.","shengdabai\u002FTony-Claude-Code-Skills","shengdabai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F116417419?v=4","01M70F6D2WY5PQV5A92BKYJQEW","Tony Sheng","01M70F6D3GAAAYZ5H4CC1G8VXM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fquality\u002Ftest-strategy-design\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"design","test strategy","strategy","test","test strategy design","e2e","frameworks","quality gate","patterns","coverage analysis","strategies","across","analysis","when","up","testing","test strategies","design patterns","unit","coverage","2026-11-10 10:12:30",false,"---\nname: test-strategy-design\ndescription: Test pyramid strategy, test design patterns, coverage analysis, and quality gate configuration. Use when designing test strategies, improving coverage, setting up automation, or defining quality gates. Covers unit, integration, and E2E testing across frameworks.\n---\n\n# Test Strategy Design\n\nSystematic patterns for designing comprehensive test strategies that balance coverage, speed, and maintainability.\n\n## When to Activate\n\n- Designing test strategy for new projects\n- Improving existing test coverage\n- Setting up test automation frameworks\n- Configuring CI\u002FCD quality gates\n- Analyzing test gaps and priorities\n- Establishing testing standards for teams\n\n## The Test Pyramid\n\nThe test pyramid guides the distribution of testing effort:\n\n```\n                 ┌─────────┐\n                 │   E2E   │  ~10% - Critical user journeys\n                 │ Tests   │  Slow, expensive, high confidence\n                 ├─────────┤\n                 │ Integr- │  ~20% - Component interactions\n                 │  ation  │  Medium speed, real dependencies\n                 ├─────────┤\n                 │  Unit   │  ~70% - Business logic\n                 │  Tests  │  Fast, isolated, cheap\n                 └─────────┘\n```\n\n### Layer Characteristics\n\n| Layer | Speed | Isolation | Confidence | Maintenance |\n|-------|-------|-----------|------------|-------------|\n| Unit | \u003C 10ms | Complete | Low per test | Low |\n| Integration | \u003C 1s | Partial | Medium | Medium |\n| E2E | \u003C 30s | None | High | High |\n\n### When to Test at Each Layer\n\n**Unit Tests** - Test here when:\n- Pure business logic\n- Algorithmic code\n- Data transformations\n- Validation rules\n- Edge cases and boundaries\n\n**Integration Tests** - Test here when:\n- Database interactions\n- API contracts\n- Service communication\n- File system operations\n- Cache behavior\n\n**E2E Tests** - Test here when:\n- Critical user journeys\n- Cross-system workflows\n- Authentication flows\n- Payment processes\n- Smoke tests for deployments\n\n## Test Design Patterns\n\n### Unit Test Patterns\n\n#### Arrange-Act-Assert (AAA)\n\n```\n\u002F\u002F Arrange: Set up test data and dependencies\nconst user = createUser({ email: 'test@example.com' });\nconst validator = new EmailValidator();\n\n\u002F\u002F Act: Execute the behavior under test\nconst result = validator.validate(user.email);\n\n\u002F\u002F Assert: Verify the expected outcome\nexpect(result.isValid).toBe(true);\n```\n\n#### One Assertion Per Test\n\nFocus each test on a single behavior:\n\n```\n\u002F\u002F Bad: Multiple unrelated assertions\ntest('user validation', () => {\n  expect(user.isValid()).toBe(true);\n  expect(user.email).toContain('@');\n  expect(user.createdAt).toBeDefined();\n});\n\n\u002F\u002F Good: Separate tests for each behavior\ntest('validates user with proper email', () => {\n  expect(user.isValid()).toBe(true);\n});\n\ntest('email contains @ symbol', () => {\n  expect(user.email).toContain('@');\n});\n```\n\n#### Descriptive Test Names\n\nTest names should describe the expected behavior:\n\n```\n\u002F\u002F Bad\ntest('email test', () => { ... });\n\n\u002F\u002F Good\ntest('rejects email without domain', () => { ... });\ntest('accepts email with subdomain', () => { ... });\ntest('trims whitespace from email input', () => { ... });\n```\n\n#### Test Data Builders\n\nCreate readable test data:\n\n```\n\u002F\u002F Builder pattern for test data\nconst user = UserBuilder.create()\n  .withEmail('test@example.com')\n  .withRole('admin')\n  .withActiveSubscription()\n  .build();\n```\n\n### Integration Test Patterns\n\n#### Test Through Public Interfaces\n\n```\n\u002F\u002F Bad: Testing internal implementation\ntest('repository uses correct SQL', () => {\n  const sql = userRepo.buildQuery();\n  expect(sql).toContain('SELECT * FROM users');\n});\n\n\u002F\u002F Good: Testing behavior through public API\ntest('finds users by email domain', async () => {\n  await userRepo.save(createUser({ email: 'a@corp.com' }));\n  await userRepo.save(createUser({ email: 'b@corp.com' }));\n\n  const users = await userRepo.findByDomain('corp.com');\n\n  expect(users).toHaveLength(2);\n});\n```\n\n#### Use Real Dependencies Where Practical\n\n```\n\u002F\u002F Prefer real database for repository tests\nbeforeAll(async () => {\n  testDb = await createTestDatabase();\n});\n\nafterEach(async () => {\n  await testDb.truncateAll();\n});\n\n\u002F\u002F Mock only external services\njest.mock('.\u002FpaymentGateway', () => ({\n  charge: jest.fn().mockResolvedValue({ success: true })\n}));\n```\n\n#### Contract Testing\n\nVerify API contracts between services:\n\n```\n\u002F\u002F Consumer contract\ndescribe('User API Contract', () => {\n  test('GET \u002Fusers\u002F:id returns user shape', async () => {\n    const response = await api.get('\u002Fusers\u002F123');\n\n    expect(response).toMatchSchema({\n      id: expect.any(String),\n      email: expect.any(String),\n      createdAt: expect.any(String),\n    });\n  });\n});\n```\n\n### E2E Test Patterns\n\n#### Critical Path Focus\n\nOnly test the most important user journeys:\n\n```\n\u002F\u002F Priority 1: Revenue-critical paths\ntest('complete purchase flow', async () => {\n  await page.addToCart(product);\n  await page.checkout();\n  await page.enterPayment(validCard);\n  await page.confirmOrder();\n\n  await expect(page.orderConfirmation).toBeVisible();\n});\n\n\u002F\u002F Priority 2: Core functionality\ntest('user registration and login', async () => {\n  await page.register(newUser);\n  await page.login(newUser);\n\n  await expect(page.dashboard).toBeVisible();\n});\n```\n\n#### Page Object Pattern\n\nEncapsulate page interactions:\n\n```\nclass CheckoutPage {\n  constructor(page) {\n    this.page = page;\n  }\n\n  async enterShippingAddress(address) {\n    await this.page.fill('#street', address.street);\n    await this.page.fill('#city', address.city);\n    await this.page.fill('#zip', address.zip);\n  }\n\n  async submitOrder() {\n    await this.page.click('[data-testid=\"submit-order\"]');\n    await this.page.waitForURL('**\u002Fconfirmation');\n  }\n}\n```\n\n#### Resilient Selectors\n\nUse stable selectors that survive UI changes:\n\n```\n\u002F\u002F Fragile: Based on CSS\u002Fposition\nawait page.click('.btn-primary');\nawait page.click('div > div:nth-child(2) > button');\n\n\u002F\u002F Stable: Based on test IDs or roles\nawait page.click('[data-testid=\"submit-button\"]');\nawait page.getByRole('button', { name: 'Submit' });\n```\n\n## Coverage Strategy\n\n### Coverage Types\n\n| Type | Measures | Target |\n|------|----------|--------|\n| Line | Lines executed | 80% |\n| Branch | Decision paths taken | 75% |\n| Function | Functions called | 90% |\n| Statement | Statements executed | 80% |\n\n### Coverage Prioritization\n\nFocus coverage on high-risk areas:\n\n```\nHigh Priority (100% coverage):\n├── Payment processing\n├── Authentication\u002FAuthorization\n├── Data validation\n├── Business rule enforcement\n└── Security-sensitive code\n\nMedium Priority (80% coverage):\n├── Core business logic\n├── API endpoints\n├── Data transformations\n└── Error handling\n\nLower Priority (60% coverage):\n├── UI components\n├── Configuration\n├── Logging\u002FMonitoring\n└── Admin features\n```\n\n### Meaningful Coverage\n\nCoverage quantity vs quality:\n\n```\n\u002F\u002F 100% coverage, low value\ntest('getter returns value', () => {\n  user.name = 'John';\n  expect(user.name).toBe('John');\n});\n\n\u002F\u002F 80% coverage, high value\ntest('rejects order when inventory insufficient', () => {\n  const inventory = createInventory({ quantity: 5 });\n  const order = createOrder({ quantity: 10 });\n\n  expect(() => processOrder(order, inventory))\n    .toThrow('Insufficient inventory');\n});\n```\n\n## Quality Gates\n\n### Gate Configuration\n\n| Gate | Threshold | Enforcement |\n|------|-----------|-------------|\n| Unit Tests | 100% pass | Block merge |\n| Integration Tests | 100% pass | Block merge |\n| E2E Tests | 100% pass | Block deploy |\n| Line Coverage | ≥ 80% | Block merge |\n| Branch Coverage | ≥ 75% | Block merge |\n| New Code Coverage | ≥ 90% | Warn |\n| Test Duration | \u003C 10 min | Warn |\n\n### Flaky Test Management\n\n```\nFlaky Test Protocol:\n1. DETECT: Track test stability over time\n2. QUARANTINE: Move flaky tests to separate suite\n3. FIX: Prioritize fixing within 1 week\n4. REINTEGRATE: Return to main suite after 10 consecutive passes\n```\n\n### Test Performance Budgets\n\n| Test Type | Target Duration | Action if Exceeded |\n|-----------|-----------------|-------------------|\n| Single Unit Test | \u003C 10ms | Investigate |\n| Unit Suite | \u003C 30s | Parallelize |\n| Single Integration | \u003C 1s | Review setup\u002Fteardown |\n| Integration Suite | \u003C 2 min | Parallelize |\n| Single E2E | \u003C 30s | Optimize waits |\n| E2E Suite | \u003C 10 min | Reduce scope |\n\n## Test Organization\n\n### File Structure\n\n```\nsrc\u002F\n├── user\u002F\n│   ├── User.ts\n│   ├── User.test.ts           # Unit tests co-located\n│   ├── UserRepository.ts\n│   └── UserRepository.test.ts\n├── order\u002F\n│   ├── Order.ts\n│   └── Order.test.ts\ntests\u002F\n├── integration\u002F\n│   ├── api\u002F\n│   │   └── users.test.ts      # API integration tests\n│   └── database\u002F\n│       └── repositories.test.ts\n└── e2e\u002F\n    ├── checkout.spec.ts       # E2E tests by journey\n    └── registration.spec.ts\n```\n\n### Test Naming Conventions\n\n```\n# Unit tests: [unit].test.ts\nUser.test.ts\nOrderCalculator.test.ts\n\n# Integration tests: [feature].integration.test.ts\nusers.integration.test.ts\npayment-gateway.integration.test.ts\n\n# E2E tests: [journey].e2e.ts or [journey].spec.ts\ncheckout.e2e.ts\nuser-onboarding.spec.ts\n```\n\n## Test Data Management\n\n### Test Data Principles\n\n1. **Isolation**: Each test manages its own data\n2. **Cleanup**: Tests clean up after themselves\n3. **Determinism**: Same test, same data, same result\n4. **Minimal**: Only create data needed for the test\n\n### Factories and Fixtures\n\n```\n\u002F\u002F Factory: Dynamic test data\nconst createUser = (overrides = {}) => ({\n  id: faker.string.uuid(),\n  email: faker.internet.email(),\n  name: faker.person.fullName(),\n  ...overrides\n});\n\n\u002F\u002F Fixture: Static reference data\nconst ADMIN_USER = {\n  id: 'admin-001',\n  email: 'admin@test.com',\n  role: 'admin'\n};\n```\n\n### Database Test Patterns\n\n```\n\u002F\u002F Transaction rollback pattern\nbeforeEach(async () => {\n  transaction = await db.beginTransaction();\n});\n\nafterEach(async () => {\n  await transaction.rollback();\n});\n\n\u002F\u002F Truncate pattern (slower but more isolated)\nafterEach(async () => {\n  await db.truncateAll();\n});\n```\n\n## CI\u002FCD Integration\n\n### Pipeline Configuration\n\n```yaml\ntest:\n  stages:\n    - lint-and-typecheck    # Fast feedback first\n    - unit-tests            # Parallel execution\n    - integration-tests     # With test database\n    - e2e-tests             # Against staging environment\n\n  parallelization:\n    unit: 4 workers\n    integration: 2 workers\n    e2e: 1 worker (sequential for stability)\n\n  artifacts:\n    - coverage reports\n    - test results (JUnit XML)\n    - E2E screenshots\u002Fvideos on failure\n```\n\n### Failure Handling\n\n```\nOn Test Failure:\n1. Capture: Screenshots, logs, database state\n2. Report: Notify team channel\n3. Block: Prevent merge\u002Fdeploy\n4. Retry: Once for E2E (flaky detection)\n```\n\n## Best Practices\n\n### Do\n\n- Test behavior, not implementation\n- Keep tests independent and isolated\n- Use meaningful, descriptive test names\n- Maintain test code like production code\n- Run tests frequently during development\n- Fix flaky tests immediately\n\n### Avoid\n\n- Testing private methods directly\n- Mocking everything (use real dependencies where practical)\n- Ignoring slow tests (fix the root cause)\n- Writing tests after bugs (write them before)\n- Sharing state between tests\n- Over-relying on E2E tests\n\n## References\n\n- [Test Pattern Examples](examples\u002Ftest-patterns.md) - Code examples for each pattern\n- [Framework-Specific Guides](reference.md) - Jest, Pytest, Go testing patterns\n","# Test Strategy Design\n\nSystematic patterns for designing comprehensive test strategies that balance coverage, speed, and maintainability.\n\n## When to Activate\n\n- Designing test strategy for new projects\n- Improving existing test coverage\n- Setting up test automation frameworks\n- Configuring CI\u002FCD quality gates\n- Analyzing test gaps and priorities\n- Establishing testing standards for teams\n\n## The Test Pyramid\n\nThe test pyramid guides the distribution of testing effort:\n\n```\n                 ┌─────────┐\n                 │   E2E   │  ~10% - Critical user journeys\n                 │ Tests   │  Slow, expensive, high confidence\n                 ├─────────┤\n                 │ Integr- │  ~20% - Component interactions\n                 │  ation  │  Medium speed, real dependencies\n                 ├─────────┤\n                 │  Unit   │  ~70% - Business logic\n                 │  Tests  │  Fast, isolated, cheap\n                 └─────────┘\n```\n\n### Layer Characteristics\n\n| Layer | Speed | Isolation | Confidence | Maintenance |\n|-------|-------|-----------|------------|-------------|\n| Unit | \u003C 10ms | Complete | Low per test | Low |\n| Integration | \u003C 1s | Partial | Medium | Medium |\n| E2E | \u003C 30s | None | High | High |\n\n### When to Test at Each Layer\n\n**Unit Tests** - Test here when:\n- Pure business logic\n- Algorithmic code\n- Data transformations\n- Validation rules\n- Edge cases and boundaries\n\n**Integration Tests** - Test here when:\n- Database interactions\n- API contracts\n- Service communication\n- File system operations\n- Cache behavior\n\n**E2E Tests** - Test here when:\n- Critical user journeys\n- Cross-system workflows\n- Authentication flows\n- Payment processes\n- Smoke tests for deployments\n\n## Test Design Patterns\n\n### Unit Test Patterns\n\n#### Arrange-Act-Assert (AAA)\n\n```\n\u002F\u002F Arrange: Set up test data and dependencies\nconst user = createUser({ email: 'test@example.com' });\nconst validator = new EmailValidator();\n\n\u002F\u002F Act: Execute the behavior under test\nconst result = validator.validate(user.email);\n\n\u002F\u002F Assert: Verify the expected outcome\nexpect(result.isValid).toBe(true);\n```\n\n#### One Assertion Per Test\n\nFocus each test on a single behavior:\n\n```\n\u002F\u002F Bad: Multiple unrelated assertions\ntest('user validation', () => {\n  expect(user.isValid()).toBe(true);\n  expect(user.email).toContain('@');\n  expect(user.createdAt).toBeDefined();\n});\n\n\u002F\u002F Good: Separate tests for each behavior\ntest('validates user with proper email', () => {\n  expect(user.isValid()).toBe(true);\n});\n\ntest('email contains @ symbol', () => {\n  expect(user.email).toContain('@');\n});\n```\n\n#### Descriptive Test Names\n\nTest names should describe the expected behavior:\n\n```\n\u002F\u002F Bad\ntest('email test', () => { ... });\n\n\u002F\u002F Good\ntest('rejects email without domain', () => { ... });\ntest('accepts email with subdomain', () => { ... });\ntest('trims whitespace from email input', () => { ... });\n```\n\n#### Test Data Builders\n\nCreate readable test data:\n\n```\n\u002F\u002F Builder pattern for test data\nconst user = UserBuilder.create()\n  .withEmail('test@example.com')\n  .withRole('admin')\n  .withActiveSubscription()\n  .build();\n```\n\n### Integration Test Patterns\n\n#### Test Through Public Interfaces\n\n```\n\u002F\u002F Bad: Testing internal implementation\ntest('repository uses correct SQL', () => {\n  const sql = userRepo.buildQuery();\n  expect(sql).toContain('SELECT * FROM users');\n});\n\n\u002F\u002F Good: Testing behavior through public API\ntest('finds users by email domain', async () => {\n  await userRepo.save(createUser({ email: 'a@corp.com' }));\n  await userRepo.save(createUser({ email: 'b@corp.com' }));\n\n  const users = await userRepo.findByDomain('corp.com');\n\n  expect(users).toHaveLength(2);\n});\n```\n\n#### Use Real Dependencies Where Practical\n\n```\n\u002F\u002F Prefer real database for repository tests\nbeforeAll(async () => {\n  testDb = await createTestDatabase();\n});\n\nafterEach(async () => {\n  await testDb.truncateAll();\n});\n\n\u002F\u002F Mock only external services\njest.mock('.\u002FpaymentGateway', () => ({\n  charge: jest.fn().mockResolvedValue({ success: true })\n}));\n```\n\n#### Contract Testing\n\nVerify API contracts between services:\n\n```\n\u002F\u002F Consumer contract\ndescribe('User API Contract', () => {\n  test('GET \u002Fusers\u002F:id returns user shape', async () => {\n    const response = await api.get('\u002Fusers\u002F123');\n\n    expect(response).toMatchSchema({\n      id: expect.any(String),\n      email: expect.any(String),\n      createdAt: expect.any(String),\n    });\n  });\n});\n```\n\n### E2E Test Patterns\n\n#### Critical Path Focus\n\nOnly test the most important user journeys:\n\n```\n\u002F\u002F Priority 1: Revenue-critical paths\ntest('complete purchase flow', async () => {\n  await page.addToCart(product);\n  await page.checkout();\n  await page.enterPayment(validCard);\n  await page.confirmOrder();\n\n  await expect(page.orderConfirmation).toBeVisible();\n});\n\n\u002F\u002F Priority 2: Core functionality\ntest('user registration and login', async () => {\n  await page.register(newUser);\n  await page.login(newUser);\n\n  await expect(page.dashboard).toBeVisible();\n});\n```\n\n#### Page Object Pattern\n\nEncapsulate page interactions:\n\n```\nclass CheckoutPage {\n  constructor(page) {\n    this.page = page;\n  }\n\n  async enterShippingAddress(address) {\n    await this.page.fill('#street', address.street);\n    await this.page.fill('#city', address.city);\n    await this.page.fill('#zip', address.zip);\n  }\n\n  async submitOrder() {\n    await this.page.click('[data-testid=\"submit-order\"]');\n    await this.page.waitForURL('**\u002Fconfirmation');\n  }\n}\n```\n\n#### Resilient Selectors\n\nUse stable selectors that survive UI changes:\n\n```\n\u002F\u002F Fragile: Based on CSS\u002Fposition\nawait page.click('.btn-primary');\nawait page.click('div > div:nth-child(2) > button');\n\n\u002F\u002F Stable: Based on test IDs or roles\nawait page.click('[data-testid=\"submit-button\"]');\nawait page.getByRole('button', { name: 'Submit' });\n```\n\n## Coverage Strategy\n\n### Coverage Types\n\n| Type | Measures | Target |\n|------|----------|--------|\n| Line | Lines executed | 80% |\n| Branch | Decision paths taken | 75% |\n| Function | Functions called | 90% |\n| Statement | Statements executed | 80% |\n\n### Coverage Prioritization\n\nFocus coverage on high-risk areas:\n\n```\nHigh Priority (100% coverage):\n├── Payment processing\n├── Authentication\u002FAuthorization\n├── Data validation\n├── Business rule enforcement\n└── Security-sensitive code\n\nMedium Priority (80% coverage):\n├── Core business logic\n├── API endpoints\n├── Data transformations\n└── Error handling\n\nLower Priority (60% coverage):\n├── UI components\n├── Configuration\n├── Logging\u002FMonitoring\n└── Admin features\n```\n\n### Meaningful Coverage\n\nCoverage quantity vs quality:\n\n```\n\u002F\u002F 100% coverage, low value\ntest('getter returns value', () => {\n  user.name = 'John';\n  expect(user.name).toBe('John');\n});\n\n\u002F\u002F 80% coverage, high value\ntest('rejects order when inventory insufficient', () => {\n  const inventory = createInventory({ quantity: 5 });\n  const order = createOrder({ quantity: 10 });\n\n  expect(() => processOrder(order, inventory))\n    .toThrow('Insufficient inventory');\n});\n```\n\n## Quality Gates\n\n### Gate Configuration\n\n| Gate | Threshold | Enforcement |\n|------|-----------|-------------|\n| Unit Tests | 100% pass | Block merge |\n| Integration Tests | 100% pass | Block merge |\n| E2E Tests | 100% pass | Block deploy |\n| Line Coverage | ≥ 80% | Block merge |\n| Branch Coverage | ≥ 75% | Block merge |\n| New Code Coverage | ≥ 90% | Warn |\n| Test Duration | \u003C 10 min | Warn |\n\n### Flaky Test Management\n\n```\nFlaky Test Protocol:\n1. DETECT: Track test stability over time\n2. QUARANTINE: Move flaky tests to separate suite\n3. FIX: Prioritize fixing within 1 week\n4. REINTEGRATE: Return to main suite after 10 consecutive passes\n```\n\n### Test Performance Budgets\n\n| Test Type | Target Duration | Action if Exceeded |\n|-----------|-----------------|-------------------|\n| Single Unit Test | \u003C 10ms | Investigate |\n| Unit Suite | \u003C 30s | Parallelize |\n| Single Integration | \u003C 1s | Review setup\u002Fteardown |\n| Integration Suite | \u003C 2 min | Parallelize |\n| Single E2E | \u003C 30s | Optimize waits |\n| E2E Suite | \u003C 10 min | Reduce scope |\n\n## Test Organization\n\n### File Structure\n\n```\nsrc\u002F\n├── user\u002F\n│   ├── User.ts\n│   ├── User.test.ts           # Unit tests co-located\n│   ├── UserRepository.ts\n│   └── UserRepository.test.ts\n├── order\u002F\n│   ├── Order.ts\n│   └── Order.test.ts\ntests\u002F\n├── integration\u002F\n│   ├── api\u002F\n│   │   └── users.test.ts      # API integration tests\n│   └── database\u002F\n│       └── repositories.test.ts\n└── e2e\u002F\n    ├── checkout.spec.ts       # E2E tests by journey\n    └── registration.spec.ts\n```\n\n### Test Naming Conventions\n\n```\n# Unit tests: [unit].test.ts\nUser.test.ts\nOrderCalculator.test.ts\n\n# Integration tests: [feature].integration.test.ts\nusers.integration.test.ts\npayment-gateway.integration.test.ts\n\n# E2E tests: [journey].e2e.ts or [journey].spec.ts\ncheckout.e2e.ts\nuser-onboarding.spec.ts\n```\n\n## Test Data Management\n\n### Test Data Principles\n\n1. **Isolation**: Each test manages its own data\n2. **Cleanup**: Tests clean up after themselves\n3. **Determinism**: Same test, same data, same result\n4. **Minimal**: Only create data needed for the test\n\n### Factories and Fixtures\n\n```\n\u002F\u002F Factory: Dynamic test data\nconst createUser = (overrides = {}) => ({\n  id: faker.string.uuid(),\n  email: faker.internet.email(),\n  name: faker.person.fullName(),\n  ...overrides\n});\n\n\u002F\u002F Fixture: Static reference data\nconst ADMIN_USER = {\n  id: 'admin-001',\n  email: 'admin@test.com',\n  role: 'admin'\n};\n```\n\n### Database Test Patterns\n\n```\n\u002F\u002F Transaction rollback pattern\nbeforeEach(async () => {\n  transaction = await db.beginTransaction();\n});\n\nafterEach(async () => {\n  await transaction.rollback();\n});\n\n\u002F\u002F Truncate pattern (slower but more isolated)\nafterEach(async () => {\n  await db.truncateAll();\n});\n```\n\n## CI\u002FCD Integration\n\n### Pipeline Configuration\n\n```yaml\ntest:\n  stages:\n    - lint-and-typecheck    # Fast feedback first\n    - unit-tests            # Parallel execution\n    - integration-tests     # With test database\n    - e2e-tests             # Against staging environment\n\n  parallelization:\n    unit: 4 workers\n    integration: 2 workers\n    e2e: 1 worker (sequential for stability)\n\n  artifacts:\n    - coverage reports\n    - test results (JUnit XML)\n    - E2E screenshots\u002Fvideos on failure\n```\n\n### Failure Handling\n\n```\nOn Test Failure:\n1. Capture: Screenshots, logs, database state\n2. Report: Notify team channel\n3. Block: Prevent merge\u002Fdeploy\n4. Retry: Once for E2E (flaky detection)\n```\n\n## Best Practices\n\n### Do\n\n- Test behavior, not implementation\n- Keep tests independent and isolated\n- Use meaningful, descriptive test names\n- Maintain test code like production code\n- Run tests frequently during development\n- Fix flaky tests immediately\n\n### Avoid\n\n- Testing private methods directly\n- Mocking everything (use real dependencies where practical)\n- Ignoring slow tests (fix the root cause)\n- Writing tests after bugs (write them before)\n- Sharing state between tests\n- Over-relying on E2E tests\n\n## References\n\n- [Test Pattern Examples](examples\u002Ftest-patterns.md) - Code examples for each pattern\n- [Framework-Specific Guides](reference.md) - Jest, Pytest, Go testing patterns\n",{"name":5,"description":7},"main","7850740bd837adb32f0a109ab2af82482196c6f2","skills\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fquality\u002Ftest-strategy-design",1,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills","https:\u002F\u002Fzturnsgo.com","https:\u002F\u002Fgithub.com\u002Fshengdabai","https:\u002F\u002Fzturnsgo.com\u002F","AI × education creator — producer, not consumer. Taught 6,000+ learners; shipping learning tools & daily essays with Claude Code, practicing @xiaolai's way 🥋","2026-11-01 21:28:23",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add shengdabai\u002FTony-Claude-Code-Skills --skill test-strategy-design",{"tool":76,"command":77},"bunx","bunx skills add shengdabai\u002FTony-Claude-Code-Skills --skill test-strategy-design",{"tool":79,"command":80},"pnpm","pnpm dlx skills add shengdabai\u002FTony-Claude-Code-Skills --skill test-strategy-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fquality\u002Ftest-strategy-design\u002FSKILL.md",true,[],[85,102,132,158,180,200],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":94,"publishedAt":55},"01M70P17DAD4C1C47NPH6A96EM","xiaolai-methodology","以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 \"李笑来\"、\"笑来\"、\"笑来老师\"、\"扮演李笑来\"、\"找笑来聊聊\"、\"笑来怎么看\"、\"xiaolai\"、\"把时间当作朋友\"、\"通往财富自由之路\"、\"定投改变命运\"、\"韭菜的自我修养\"、\"自学是门手艺\"、\"让时间陪你慢慢变富\"、\"七年就是一辈子\"、\"元认知\"、\"活在未来\"、\"复利\u002F长期主义\"、\"践行\"、\"痴迷改进\"、\"个人商业模式\u002F出售时间\"、\"睡后收入\"、\"定投\"、\"财富自由\"、\"操作系统升级\"、\"最少必要知识\"、\"北极星提示词\"、\"用 AI 该怎么学\u002F思考\" 等任一触发词,或当用户带着关于创业\u002F赚钱\u002F投资\u002F学习\u002F职业\u002F重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fxiaolai-methodology\u002FSKILL.md",[91],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",[95,96,97,98,99,100,101],"methodology","xiaolai","xiaolai methodology","朋友","投资","writing","收入",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":112,"publishedAt":55},"01M70P13NB9YP7ACJR1S861CDS","zread","Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `.\u002F.zread\u002Fwiki\u002F`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module\u002Fpackage explanations, or \"what does this repo do\"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread \u002F zread.ai directly. Also use it proactively before diving into a large unknown repo — if `.\u002F.zread\u002Fwiki\u002Fcurrent` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word \"zread\".","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fzread\u002FSKILL.md",[108,109],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师",[104,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131],"knowledge","wiki","explore","walkthrough","project","get","knowledge base","run","generate","intent","cli","map","documentation","project wiki","disk","architecture","code","unknown","generated",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":142,"publishedAt":55},"01M70P10S4SWMZQ8BJAFBFDRW3","youtube","Launch the YouTube Creator Agent to auto-generate videos.\nUse when: user types \u002Fyoutube, wants to create YouTube videos,\ngenerate video content, or upload to YouTube.\nKeywords: youtube, video, 视频, 创作视频, 发布视频","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube\u002FSKILL.md",[138,139],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":140,"categoryName":141,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者",[134,143,144,145,146,147,148,149,121,150,151,152,48,153,154,155,156,157],"user","content","视频","creator","generate video","videos","launch","video content","create","upload","use","auto","types","Video","创作",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"publishedAt":55},"01M70P0YE95D8BACZCGV8BK90K","youtube-script-sync","Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新\u002F同步\u002F优化 Youtube视频逐字稿知识库”, or says “更新\u002F同步\u002F优化该知识库” while this knowledge base is the active context.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-sync\u002FSKILL.md",[164],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[166,167,134,168,169,156,170,171,172,173,174,175,176,177,119,178,48,153,113,179],"sync","script","youtube script sync","recording","shorts","first","base","person","update","active","child","optimize","idempotent","long",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":190,"publishedAt":55},"01M70P0WMV5XT0EEC0N445PW07","writing-skills","How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-skills\u002FSKILL.md",[186,187,188,189],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":140,"categoryName":141,"taxonomyType":32,"taxonomyTypeDesc":33},[191,100,192,193,194,195,129,48,153,196,197,198,199],"writing skills","how","teach","write skill","write","claude code skills","files","how to","trigger",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":208,"publishedAt":55},"01M70P0SJFR4YVJQBGMHKGSKXT","writing-rules","How to write .claude\u002Frules\u002F files that Claude actually follows. Use when creating, improving, or reviewing project rules.","https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fxiaolai\u002Fnlpm\u002Fskills\u002Fnlpm\u002Fwriting-rules\u002FSKILL.md",[206,207],{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":140,"categoryName":141,"taxonomyType":32,"taxonomyTypeDesc":33},[209,100,210,117,211,197,48,192,195,153,198],"Rules","writing rules","project rules"]