[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ48350058BYTCX7F1BJDF":3,"skill-same:01M6QJ48350058BYTCX7F1BJDF":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":13,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6QJ48350058BYTCX7F1BJDF","setup-test-data",null,"Master test data setup: creating meaningful test fixtures, test data factories, and managing test data lifecycle. Use when user needs test data, test fixtures, sample data for tests, or when tests are hard to maintain due to data setup. Triggers especially when user says \"test fixtures\", \"test data\", \"setup test\", \"create test objects\", or \"sample data\".","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fsetup-test-data\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"setup","setup test data","test data","test","data","create","create test","for","data management","triggers","tests","fixtures","sample","objects","maintain","master","use","management","coding","lifecycle","2026-11-10 10:12:30",false,"---\nname: setup-test-data\ndescription: >-\n  Master test data setup: creating meaningful test fixtures, test data factories, and managing test data lifecycle. Use when user needs test data, test fixtures, sample data for tests, or when tests are hard to maintain due to data setup. Triggers especially when user says \"test fixtures\", \"test data\", \"setup test\", \"create test objects\", or \"sample data\".\ncategory: coding\npriority: P2\ntrigger_patterns:\n  - \"test fixtures\"\n  - \"test data\"\n  - \"setup test\"\n  - \"create test objects\"\n  - \"sample data\"\n  - \"test data management\"\n---\n\n# Setup Test Data — Strategic Test Fixture Design\n\n## Overview\n\nSetup-test-data is a **behavioral specification skill** that encapsulates the methodology for **creating maintainable, meaningful test data that makes tests readable and robust**.\n\nThis skill embodies the expertise of developers who've written tests with messy inline data and those who've used well-designed fixtures — and know the difference in maintainability.\n\n## Core Philosophy\n\n### The Test Data Principle\n\n> \"Test data should tell a story. When you read a test, you should immediately understand what scenario it's testing without deciphering random strings or magic numbers.\"\n\n### Good vs Bad Test Data\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    TEST DATA QUALITY                           │\n│                                                               │\n│    BAD TEST DATA:                  GOOD TEST DATA:           │\n│    ─────────────                  ──────────────             │\n│    const x = \"asdf\";              const activeUser = {...};  │\n│    const y = 12345;               const premiumUser = {...}; │\n│    const z = true;                const guestUser = {...};  │\n│                                                               │\n│    Meaningless                     Self-documenting           │\n│    Hard to understand             Clear intent               │\n│    Brittle                        Flexible                   │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Decision Framework\n\n### Test Data Strategy Selection\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                  TEST DATA STRATEGY MATRIX                    │\n│                                                               │\n│    STRATEGY          USE WHEN              AVOID WHEN         │\n│    ─────────         ─────────            ──────────         │\n│    Inline data       Simple, one-off      Repeated use       │\n│    Constants         Shared values         Complex objects     │\n│    Factories         Dynamic creation      Simple tests       │\n│    Fixtures          Complex state         Fast tests needed  │\n│    Builders          Many optional fields   Simple tests       │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### When to Use Each Approach\n\n| Approach | Best For | Avoid When |\n|----------|---------|-----------|\n| Inline | One test, simple case | Multiple tests, complex data |\n| Constants | Shared test values | Tests need variations |\n| Factories | Creating variations | Setup is complex |\n| Fixtures | Shared complex state | Data changes frequently |\n| Builders | Flexible object creation | Simple data |\n\n## Behavioral Specification\n\n### Phase 1: Test Data Design Principles\n\n#### 1.1 The Meaningful Data Rule\n\n```typescript\n\u002F\u002F ❌ BAD: What is this?\nconst user = {\n  id: 123,\n  name: \"John\",\n  email: \"john@example.com\",\n  active: true,\n};\n\n\u002F\u002F ✅ GOOD: Clear from context\nconst testUser = {\n  id: \"user_test_123\",\n  email: \"testuser@example.com\",\n  name: \"Test User\",\n  role: \"customer\",\n  isActive: true,\n};\n\n\u002F\u002F Even better: Named for the scenario\nconst activeCustomer = {\n  id: \"customer_active_001\",\n  email: \"customer@example.com\",\n  status: \"active\",\n  subscription: \"premium\",\n};\n\nconst inactiveUser = {\n  id: \"user_inactive_001\",\n  email: \"inactive@example.com\",\n  status: \"inactive\",\n  subscription: null,\n};\n```\n\n#### 1.2 Self-Documenting Data\n\n```typescript\n\u002F\u002F ❌ BAD: No context\nconst result = calculate(100, 20);\n\n\u002F\u002F ✅ GOOD: Clear expectations\nconst order = {\n  subtotal: 100,\n  taxRate: 0.2,\n  expectedTotal: 120,\n};\nconst result = calculate(order.subtotal, order.taxRate);\nexpect(result).toBe(order.expectedTotal);\n```\n\n### Phase 2: Test Data Patterns\n\n#### 2.1 Factory Pattern\n\n```typescript\n\u002F\u002F Factory for flexible test object creation\nfunction createUser(overrides?: Partial\u003CUser>): User {\n  const defaultUser: User = {\n    id: \"user_default_001\",\n    email: \"default@example.com\",\n    name: \"Default User\",\n    role: \"customer\",\n    isActive: true,\n    createdAt: new Date(\"2024-01-01\"),\n    updatedAt: new Date(\"2024-01-01\"),\n  };\n\n  return { ...defaultUser, ...overrides };\n}\n\n\u002F\u002F Usage: Create variations easily\nconst activeUser = createUser({ isActive: true });\nconst adminUser = createUser({ role: \"admin\" });\nconst inactiveUser = createUser({ isActive: false });\nconst premiumUser = createUser({ subscription: \"premium\" });\n```\n\n#### 2.2 Builder Pattern\n\n```typescript\n\u002F\u002F Builder for complex objects\nclass UserBuilder {\n  private user: Partial\u003CUser> = {\n    id: \"user_test_001\",\n  };\n\n  withName(name: string): this {\n    this.user.name = name;\n    return this;\n  }\n\n  withEmail(email: string): this {\n    this.user.email = email;\n    return this;\n  }\n\n  asAdmin(): this {\n    this.user.role = \"admin\";\n    this.user.isAdmin = true;\n    return this;\n  }\n\n  withPremiumSubscription(): this {\n    this.user.subscription = \"premium\";\n    this.user.subscriptionEndsAt = new Date(\"2025-01-01\");\n    return this;\n  }\n\n  build(): User {\n    return { ...defaultUser, ...this.user } as User;\n  }\n}\n\n\u002F\u002F Usage: Chain readable methods\nconst premiumAdmin = new UserBuilder()\n  .withName(\"Premium Admin\")\n  .withEmail(\"admin@example.com\")\n  .asAdmin()\n  .withPremiumSubscription()\n  .build();\n```\n\n#### 2.3 Fixture Pattern\n\n```typescript\n\u002F\u002F Shared fixtures for complex state\nconst sharedFixtures = {\n  \u002F\u002F Database state\n  emptyDatabase: async () => {\n    await db.clear();\n  },\n\n  databaseWithUsers: async () => {\n    await db.clear();\n    await db.users.bulkCreate([\n      createUser({ name: \"User 1\" }),\n      createUser({ name: \"User 2\" }),\n    ]);\n  },\n\n  \u002F\u002F Complex business state\n  orderInProgress: (): Order => ({\n    id: \"order_pending_001\",\n    status: \"pending\",\n    items: [\n      { productId: \"prod_1\", quantity: 2, price: 10 },\n    ],\n    customer: createCustomer({ name: \"Pending Customer\" }),\n  }),\n\n  orderShipped: (): Order => ({\n    ...orderInProgress(),\n    status: \"shipped\",\n    shippedAt: new Date(),\n    trackingNumber: \"TRACK123\",\n  }),\n};\n\n\u002F\u002F Usage in tests\nbeforeEach(async () => {\n  await sharedFixtures.emptyDatabase();\n});\n\nit(\"should process order\", async () => {\n  const order = sharedFixtures.orderInProgress();\n  const result = await processOrder(order);\n  expect(result.status).toBe(\"completed\");\n});\n```\n\n### Phase 3: Test Data Best Practices\n\n#### 3.1 Data That Reveals Intent\n\n```typescript\n\u002F\u002F ❌ BAD: Random-looking data\nconst payment = {\n  amount: 938475,\n  currency: \"USD\",\n  card: \"4111111111111111\",\n};\n\n\u002F\u002F ✅ GOOD: Intent-revealing data\nconst payment = {\n  amount: 99.99, \u002F\u002F Clear price point\n  currency: \"USD\",\n  card: \"4111111111111111\", \u002F\u002F Valid test card number\n};\n```\n\n#### 3.2 Edge Case Data\n\n```typescript\n\u002F\u002F Explicit edge cases\nconst testCases = {\n  emptyString: { name: \"\" },\n  singleCharacter: { name: \"A\" },\n  veryLong: { name: \"A\".repeat(1000)) },\n  unicode: { name: \"日本語テスト\" },\n  sqlInjection: { name: \"'; DROP TABLE users; --\" },\n  xssAttempt: { name: \"\u003Cscript>alert('xss')\u003C\u002Fscript>\" },\n};\n\n\u002F\u002F Easy to find and understand\nit.each([\n  [\"empty string\", testCases.emptyString],\n  [\"single character\", testCases.singleCharacter],\n  [\"very long name\", testCases.veryLong],\n])(\"should handle %s\", (caseName, data) => {\n  \u002F\u002F Test logic\n});\n```\n\n#### 3.3 Realistic Data\n\n```typescript\n\u002F\u002F ❌ BAD: Fake-looking\nconst user = {\n  name: \"John Doe\",\n  email: \"john@asdf.com\",\n  company: \"XYZ Corp\",\n};\n\n\u002F\u002F ✅ GOOD: Realistic\nconst user = {\n  name: \"Sarah Chen\",\n  email: \"sarah.chen@techstartup.io\",\n  company: \"Acme Technologies\",\n  role: \"Senior Software Engineer\",\n  department: \"Platform Engineering\",\n};\n```\n\n## Common Scenarios\n\n### Scenario 1: \"My test has too much setup\"\n\n```typescript\n\u002F\u002F BEFORE: 50 lines of setup\nit(\"should send email when order ships\", async () => {\n  const user = {\n    id: \"user_123\",\n    email: \"test@example.com\",\n    name: \"Test User\",\n    preferences: { emailNotifications: true },\n    \u002F\u002F ... 20 more fields\n  };\n  const order = {\n    id: \"order_456\",\n    items: [...],\n    shippingAddress: {...},\n    \u002F\u002F ... 15 more fields\n  };\n  \u002F\u002F 100 lines of setup for a simple test\n});\n\n\u002F\u002F AFTER: Factory with meaningful defaults\nit(\"should send email when order ships\", async () => {\n  const user = createUser({\n    email: \"test@example.com\",\n    preferences: { emailNotifications: true },\n  });\n  const order = createOrder({\n    status: \"pending\",\n    customer: user,\n  });\n  \u002F\u002F 10 lines of setup, clear intent\n});\n```\n\n### Scenario 2: \"Tests fail because data changes\"\n\n```typescript\n\u002F\u002F PROBLEM: Hard-coded dates break over time\nconst user = {\n  createdAt: new Date(\"2024-01-01\"),\n  subscriptionEnds: new Date(\"2024-12-31\"),\n};\n\n\u002F\u002F SOLUTION: Relative dates\nconst user = {\n  createdAt: subDays(new Date(), 30), \u002F\u002F 30 days ago\n  subscriptionEnds: addDays(new Date(), 335), \u002F\u002F ~1 year from now\n};\n\n\u002F\u002F OR: Stable fixture dates\nconst FIXED_DATE = new Date(\"2024-06-15T12:00:00Z\");\nconst user = {\n  createdAt: FIXED_DATE,\n};\n```\n\n### Scenario 3: \"Need to test with multiple variations\"\n\n```typescript\n\u002F\u002F BEFORE: Repeated setup\nit(\"should handle premium user\", () => {\n  const user = createUser({ subscription: \"premium\" });\n  \u002F\u002F test\n});\n\nit(\"should handle free user\", () => {\n  const user = createUser({ subscription: \"free\" });\n  \u002F\u002F test\n});\n\nit(\"should handle expired subscription\", () => {\n  const user = createUser({ subscription: \"expired\" });\n  \u002F\u002F test\n});\n\n\u002F\u002F AFTER: Parametrized tests\ndescribe.each([\n  [\"premium\", \"premium\"],\n  [\"free\", \"free\"],\n  [\"expired\", \"expired\"],\n])(\"subscription type: %s\", (name, subscription) => {\n  it(\"should handle correctly\", () => {\n    const user = createUser({ subscription });\n    \u002F\u002F test once, covers all\n  });\n});\n```\n\n## Test Data Anti-Patterns\n\n### 1. Magic Numbers\n\n```typescript\n\u002F\u002F ❌ BAD\nif (user.permissions === 0b1001) { ... }\n\n\u002F\u002F ✅ GOOD\nconst PERMISSIONS = {\n  READ: 1,\n  WRITE: 2,\n  DELETE: 4,\n  ADMIN: 8,\n};\nif (user.permissions === PERMISSIONS.READ | PERMISSIONS.WRITE) { ... }\n```\n\n### 2. Duplicate Data Creation\n\n```typescript\n\u002F\u002F ❌ BAD\nit(\"test 1\", () => {\n  const user = { name: \"Test\", email: \"test@test.com\" };\n  \u002F\u002F ...\n});\n\nit(\"test 2\", () => {\n  const user = { name: \"Test\", email: \"test@test.com\" }; \u002F\u002F Duplicated!\n  \u002F\u002F ...\n});\n\n\u002F\u002F ✅ GOOD\nconst testUser = { name: \"Test\", email: \"test@test.com\" };\n\nit(\"test 1\", () => {\n  \u002F\u002F use testUser\n});\n\nit(\"test 2\", () => {\n  \u002F\u002F use testUser\n});\n```\n\n### 3. Overly Complex Fixtures\n\n```typescript\n\u002F\u002F ❌ BAD: Fixture does too much\nconst userFixture = {\n  \u002F\u002F 100 fields with obscure defaults\n  \u002F\u002F Helper methods that complicate things\n  \u002F\u002F Complex setup logic\n};\n\n\u002F\u002F ✅ GOOD: Composable, focused fixtures\nconst baseUser = { \u002F* essential fields *\u002F };\nconst adminUser = { ...baseUser, role: \"admin\" };\nconst premiumUser = { ...baseUser, subscription: \"premium\" };\n```\n\n## The Test Data Design Checklist\n\n```\nTEST DATA DESIGN CHECKLIST\n===========================\n\n□ 1. Can you understand the test from the data alone?\n□ 2. Is the data self-documenting?\n□ 3. Does the name reveal intent?\n□ 4. Are edge cases explicit?\n□ 5. Is the data realistic?\n□ 6. Can you create variations easily?\n□ 7. Is setup minimal but complete?\n□ 8. Will this break in 6 months?\n□ 9. Can someone new understand this?\n□ 10. Is there any magic data (explain if necessary)?\n\nPATTERN SELECTION:\n□ Inline → Simple, one-off test\n□ Constants → Shared values across tests\n□ Factory → Dynamic creation with defaults\n□ Builder → Complex objects with many options\n□ Fixture → Shared complex state\n```\n\n## Key Principles\n\n### 1. Data Reveals Intent\n\nThe test data should tell you what scenario is being tested without reading the test logic.\n\n### 2. Self-Documenting Names\n\nVariables and values should explain themselves. No need for extra comments.\n\n### 3. Composable, Not Monolithic\n\nBuild test objects from smaller pieces, not one giant fixture.\n\n### 4. Stable Over Time\n\nUse relative dates or fixed test dates. Don't let tests break naturally.\n\n### 5. Realistic but Controlled\n\nUse real-world patterns but controlled values. Credit card numbers should pass validation.\n\n## Relationship to Other Skills\n\n- `test-think` — Decides what test data is needed\n- `generate-mock` — Often used alongside test data\n- `intelligent-test-creation` — Combines with test design\n- `debug-test` — When test data causes failures\n- `test-readability` — Data organization affects readability\n","# Setup Test Data — Strategic Test Fixture Design\n\n## Overview\n\nSetup-test-data is a **behavioral specification skill** that encapsulates the methodology for **creating maintainable, meaningful test data that makes tests readable and robust**.\n\nThis skill embodies the expertise of developers who've written tests with messy inline data and those who've used well-designed fixtures — and know the difference in maintainability.\n\n## Core Philosophy\n\n### The Test Data Principle\n\n> \"Test data should tell a story. When you read a test, you should immediately understand what scenario it's testing without deciphering random strings or magic numbers.\"\n\n### Good vs Bad Test Data\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    TEST DATA QUALITY                           │\n│                                                               │\n│    BAD TEST DATA:                  GOOD TEST DATA:           │\n│    ─────────────                  ──────────────             │\n│    const x = \"asdf\";              const activeUser = {...};  │\n│    const y = 12345;               const premiumUser = {...}; │\n│    const z = true;                const guestUser = {...};  │\n│                                                               │\n│    Meaningless                     Self-documenting           │\n│    Hard to understand             Clear intent               │\n│    Brittle                        Flexible                   │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Decision Framework\n\n### Test Data Strategy Selection\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                  TEST DATA STRATEGY MATRIX                    │\n│                                                               │\n│    STRATEGY          USE WHEN              AVOID WHEN         │\n│    ─────────         ─────────            ──────────         │\n│    Inline data       Simple, one-off      Repeated use       │\n│    Constants         Shared values         Complex objects     │\n│    Factories         Dynamic creation      Simple tests       │\n│    Fixtures          Complex state         Fast tests needed  │\n│    Builders          Many optional fields   Simple tests       │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### When to Use Each Approach\n\n| Approach | Best For | Avoid When |\n|----------|---------|-----------|\n| Inline | One test, simple case | Multiple tests, complex data |\n| Constants | Shared test values | Tests need variations |\n| Factories | Creating variations | Setup is complex |\n| Fixtures | Shared complex state | Data changes frequently |\n| Builders | Flexible object creation | Simple data |\n\n## Behavioral Specification\n\n### Phase 1: Test Data Design Principles\n\n#### 1.1 The Meaningful Data Rule\n\n```typescript\n\u002F\u002F ❌ BAD: What is this?\nconst user = {\n  id: 123,\n  name: \"John\",\n  email: \"john@example.com\",\n  active: true,\n};\n\n\u002F\u002F ✅ GOOD: Clear from context\nconst testUser = {\n  id: \"user_test_123\",\n  email: \"testuser@example.com\",\n  name: \"Test User\",\n  role: \"customer\",\n  isActive: true,\n};\n\n\u002F\u002F Even better: Named for the scenario\nconst activeCustomer = {\n  id: \"customer_active_001\",\n  email: \"customer@example.com\",\n  status: \"active\",\n  subscription: \"premium\",\n};\n\nconst inactiveUser = {\n  id: \"user_inactive_001\",\n  email: \"inactive@example.com\",\n  status: \"inactive\",\n  subscription: null,\n};\n```\n\n#### 1.2 Self-Documenting Data\n\n```typescript\n\u002F\u002F ❌ BAD: No context\nconst result = calculate(100, 20);\n\n\u002F\u002F ✅ GOOD: Clear expectations\nconst order = {\n  subtotal: 100,\n  taxRate: 0.2,\n  expectedTotal: 120,\n};\nconst result = calculate(order.subtotal, order.taxRate);\nexpect(result).toBe(order.expectedTotal);\n```\n\n### Phase 2: Test Data Patterns\n\n#### 2.1 Factory Pattern\n\n```typescript\n\u002F\u002F Factory for flexible test object creation\nfunction createUser(overrides?: Partial\u003CUser>): User {\n  const defaultUser: User = {\n    id: \"user_default_001\",\n    email: \"default@example.com\",\n    name: \"Default User\",\n    role: \"customer\",\n    isActive: true,\n    createdAt: new Date(\"2024-01-01\"),\n    updatedAt: new Date(\"2024-01-01\"),\n  };\n\n  return { ...defaultUser, ...overrides };\n}\n\n\u002F\u002F Usage: Create variations easily\nconst activeUser = createUser({ isActive: true });\nconst adminUser = createUser({ role: \"admin\" });\nconst inactiveUser = createUser({ isActive: false });\nconst premiumUser = createUser({ subscription: \"premium\" });\n```\n\n#### 2.2 Builder Pattern\n\n```typescript\n\u002F\u002F Builder for complex objects\nclass UserBuilder {\n  private user: Partial\u003CUser> = {\n    id: \"user_test_001\",\n  };\n\n  withName(name: string): this {\n    this.user.name = name;\n    return this;\n  }\n\n  withEmail(email: string): this {\n    this.user.email = email;\n    return this;\n  }\n\n  asAdmin(): this {\n    this.user.role = \"admin\";\n    this.user.isAdmin = true;\n    return this;\n  }\n\n  withPremiumSubscription(): this {\n    this.user.subscription = \"premium\";\n    this.user.subscriptionEndsAt = new Date(\"2025-01-01\");\n    return this;\n  }\n\n  build(): User {\n    return { ...defaultUser, ...this.user } as User;\n  }\n}\n\n\u002F\u002F Usage: Chain readable methods\nconst premiumAdmin = new UserBuilder()\n  .withName(\"Premium Admin\")\n  .withEmail(\"admin@example.com\")\n  .asAdmin()\n  .withPremiumSubscription()\n  .build();\n```\n\n#### 2.3 Fixture Pattern\n\n```typescript\n\u002F\u002F Shared fixtures for complex state\nconst sharedFixtures = {\n  \u002F\u002F Database state\n  emptyDatabase: async () => {\n    await db.clear();\n  },\n\n  databaseWithUsers: async () => {\n    await db.clear();\n    await db.users.bulkCreate([\n      createUser({ name: \"User 1\" }),\n      createUser({ name: \"User 2\" }),\n    ]);\n  },\n\n  \u002F\u002F Complex business state\n  orderInProgress: (): Order => ({\n    id: \"order_pending_001\",\n    status: \"pending\",\n    items: [\n      { productId: \"prod_1\", quantity: 2, price: 10 },\n    ],\n    customer: createCustomer({ name: \"Pending Customer\" }),\n  }),\n\n  orderShipped: (): Order => ({\n    ...orderInProgress(),\n    status: \"shipped\",\n    shippedAt: new Date(),\n    trackingNumber: \"TRACK123\",\n  }),\n};\n\n\u002F\u002F Usage in tests\nbeforeEach(async () => {\n  await sharedFixtures.emptyDatabase();\n});\n\nit(\"should process order\", async () => {\n  const order = sharedFixtures.orderInProgress();\n  const result = await processOrder(order);\n  expect(result.status).toBe(\"completed\");\n});\n```\n\n### Phase 3: Test Data Best Practices\n\n#### 3.1 Data That Reveals Intent\n\n```typescript\n\u002F\u002F ❌ BAD: Random-looking data\nconst payment = {\n  amount: 938475,\n  currency: \"USD\",\n  card: \"4111111111111111\",\n};\n\n\u002F\u002F ✅ GOOD: Intent-revealing data\nconst payment = {\n  amount: 99.99, \u002F\u002F Clear price point\n  currency: \"USD\",\n  card: \"4111111111111111\", \u002F\u002F Valid test card number\n};\n```\n\n#### 3.2 Edge Case Data\n\n```typescript\n\u002F\u002F Explicit edge cases\nconst testCases = {\n  emptyString: { name: \"\" },\n  singleCharacter: { name: \"A\" },\n  veryLong: { name: \"A\".repeat(1000)) },\n  unicode: { name: \"日本語テスト\" },\n  sqlInjection: { name: \"'; DROP TABLE users; --\" },\n  xssAttempt: { name: \"\u003Cscript>alert('xss')\u003C\u002Fscript>\" },\n};\n\n\u002F\u002F Easy to find and understand\nit.each([\n  [\"empty string\", testCases.emptyString],\n  [\"single character\", testCases.singleCharacter],\n  [\"very long name\", testCases.veryLong],\n])(\"should handle %s\", (caseName, data) => {\n  \u002F\u002F Test logic\n});\n```\n\n#### 3.3 Realistic Data\n\n```typescript\n\u002F\u002F ❌ BAD: Fake-looking\nconst user = {\n  name: \"John Doe\",\n  email: \"john@asdf.com\",\n  company: \"XYZ Corp\",\n};\n\n\u002F\u002F ✅ GOOD: Realistic\nconst user = {\n  name: \"Sarah Chen\",\n  email: \"sarah.chen@techstartup.io\",\n  company: \"Acme Technologies\",\n  role: \"Senior Software Engineer\",\n  department: \"Platform Engineering\",\n};\n```\n\n## Common Scenarios\n\n### Scenario 1: \"My test has too much setup\"\n\n```typescript\n\u002F\u002F BEFORE: 50 lines of setup\nit(\"should send email when order ships\", async () => {\n  const user = {\n    id: \"user_123\",\n    email: \"test@example.com\",\n    name: \"Test User\",\n    preferences: { emailNotifications: true },\n    \u002F\u002F ... 20 more fields\n  };\n  const order = {\n    id: \"order_456\",\n    items: [...],\n    shippingAddress: {...},\n    \u002F\u002F ... 15 more fields\n  };\n  \u002F\u002F 100 lines of setup for a simple test\n});\n\n\u002F\u002F AFTER: Factory with meaningful defaults\nit(\"should send email when order ships\", async () => {\n  const user = createUser({\n    email: \"test@example.com\",\n    preferences: { emailNotifications: true },\n  });\n  const order = createOrder({\n    status: \"pending\",\n    customer: user,\n  });\n  \u002F\u002F 10 lines of setup, clear intent\n});\n```\n\n### Scenario 2: \"Tests fail because data changes\"\n\n```typescript\n\u002F\u002F PROBLEM: Hard-coded dates break over time\nconst user = {\n  createdAt: new Date(\"2024-01-01\"),\n  subscriptionEnds: new Date(\"2024-12-31\"),\n};\n\n\u002F\u002F SOLUTION: Relative dates\nconst user = {\n  createdAt: subDays(new Date(), 30), \u002F\u002F 30 days ago\n  subscriptionEnds: addDays(new Date(), 335), \u002F\u002F ~1 year from now\n};\n\n\u002F\u002F OR: Stable fixture dates\nconst FIXED_DATE = new Date(\"2024-06-15T12:00:00Z\");\nconst user = {\n  createdAt: FIXED_DATE,\n};\n```\n\n### Scenario 3: \"Need to test with multiple variations\"\n\n```typescript\n\u002F\u002F BEFORE: Repeated setup\nit(\"should handle premium user\", () => {\n  const user = createUser({ subscription: \"premium\" });\n  \u002F\u002F test\n});\n\nit(\"should handle free user\", () => {\n  const user = createUser({ subscription: \"free\" });\n  \u002F\u002F test\n});\n\nit(\"should handle expired subscription\", () => {\n  const user = createUser({ subscription: \"expired\" });\n  \u002F\u002F test\n});\n\n\u002F\u002F AFTER: Parametrized tests\ndescribe.each([\n  [\"premium\", \"premium\"],\n  [\"free\", \"free\"],\n  [\"expired\", \"expired\"],\n])(\"subscription type: %s\", (name, subscription) => {\n  it(\"should handle correctly\", () => {\n    const user = createUser({ subscription });\n    \u002F\u002F test once, covers all\n  });\n});\n```\n\n## Test Data Anti-Patterns\n\n### 1. Magic Numbers\n\n```typescript\n\u002F\u002F ❌ BAD\nif (user.permissions === 0b1001) { ... }\n\n\u002F\u002F ✅ GOOD\nconst PERMISSIONS = {\n  READ: 1,\n  WRITE: 2,\n  DELETE: 4,\n  ADMIN: 8,\n};\nif (user.permissions === PERMISSIONS.READ | PERMISSIONS.WRITE) { ... }\n```\n\n### 2. Duplicate Data Creation\n\n```typescript\n\u002F\u002F ❌ BAD\nit(\"test 1\", () => {\n  const user = { name: \"Test\", email: \"test@test.com\" };\n  \u002F\u002F ...\n});\n\nit(\"test 2\", () => {\n  const user = { name: \"Test\", email: \"test@test.com\" }; \u002F\u002F Duplicated!\n  \u002F\u002F ...\n});\n\n\u002F\u002F ✅ GOOD\nconst testUser = { name: \"Test\", email: \"test@test.com\" };\n\nit(\"test 1\", () => {\n  \u002F\u002F use testUser\n});\n\nit(\"test 2\", () => {\n  \u002F\u002F use testUser\n});\n```\n\n### 3. Overly Complex Fixtures\n\n```typescript\n\u002F\u002F ❌ BAD: Fixture does too much\nconst userFixture = {\n  \u002F\u002F 100 fields with obscure defaults\n  \u002F\u002F Helper methods that complicate things\n  \u002F\u002F Complex setup logic\n};\n\n\u002F\u002F ✅ GOOD: Composable, focused fixtures\nconst baseUser = { \u002F* essential fields *\u002F };\nconst adminUser = { ...baseUser, role: \"admin\" };\nconst premiumUser = { ...baseUser, subscription: \"premium\" };\n```\n\n## The Test Data Design Checklist\n\n```\nTEST DATA DESIGN CHECKLIST\n===========================\n\n□ 1. Can you understand the test from the data alone?\n□ 2. Is the data self-documenting?\n□ 3. Does the name reveal intent?\n□ 4. Are edge cases explicit?\n□ 5. Is the data realistic?\n□ 6. Can you create variations easily?\n□ 7. Is setup minimal but complete?\n□ 8. Will this break in 6 months?\n□ 9. Can someone new understand this?\n□ 10. Is there any magic data (explain if necessary)?\n\nPATTERN SELECTION:\n□ Inline → Simple, one-off test\n□ Constants → Shared values across tests\n□ Factory → Dynamic creation with defaults\n□ Builder → Complex objects with many options\n□ Fixture → Shared complex state\n```\n\n## Key Principles\n\n### 1. Data Reveals Intent\n\nThe test data should tell you what scenario is being tested without reading the test logic.\n\n### 2. Self-Documenting Names\n\nVariables and values should explain themselves. No need for extra comments.\n\n### 3. Composable, Not Monolithic\n\nBuild test objects from smaller pieces, not one giant fixture.\n\n### 4. Stable Over Time\n\nUse relative dates or fixed test dates. Don't let tests break naturally.\n\n### 5. Realistic but Controlled\n\nUse real-world patterns but controlled values. Credit card numbers should pass validation.\n\n## Relationship to Other Skills\n\n- `test-think` — Decides what test data is needed\n- `generate-mock` — Often used alongside test data\n- `intelligent-test-creation` — Combines with test design\n- `debug-test` — When test data causes failures\n- `test-readability` — Data organization affects readability\n",{"name":5,"category":46,"priority":53,"description":7,"trigger_patterns":54},"P2",[55,30,56,57,58,59],"test fixtures","setup test","create test objects","sample data","test data management","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Fsetup-test-data","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill setup-test-data",{"tool":72,"command":73},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill setup-test-data",{"tool":75,"command":76},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill setup-test-data","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fsetup-test-data\u002FSKILL.md",true,[],[81,111,132,160,193,218],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":93,"publishedAt":48},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[87,90],{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":91,"categoryName":92,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000034","行政与办公人员",[94,95,96,97,98,99,100,101,102,103,83,60,104,105,106,107,108,109,110,35],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":48},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[118,119,120,97,98,99,121,122,123,124,125,126,60,127,128,129,130,108,109,131],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","structure","authoring","software","principles","high",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":145,"publishedAt":48},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[138,141,142],{"categoryNo":139,"categoryName":140,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":143,"categoryName":144,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者",[146,147,97,148,149,118,150,151,152,153,154,155,60,156,157,128,158,159,108,35],"doc coauthoring","doc","workflow","official","tasks","decision","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":174,"publishedAt":48},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[166,169,170,171],{"categoryNo":167,"categoryName":168,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":172,"categoryName":173,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师",[175,176,148,177,178,179,180,31,181,182,183,184,185,186,187,188,189,190,191,192],"code review","review","code","code review workflow","testing","frontend","change","code quality","code-review","analysis","check","coverage","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":208,"publishedAt":48},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer","Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[199,200,203,204,205],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":201,"categoryName":202,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":172,"categoryName":173,"taxonomyType":25,"taxonomyTypeDesc":26},{"categoryNo":206,"categoryName":207,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[31,181,177,209,210,179,211,212,148,213,183,214,186,215,60,38,216,217,35,192],"designer","code change test designer","design","diffs","commit","edge","diff","flows","which",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":48},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[224],{"categoryNo":88,"categoryName":89,"taxonomyType":20,"taxonomyTypeDesc":21},[226,227,228,229,149,230,33,231,232,233,184,234,235,236,60,237,238,108,35,220],"skill creator","creator","performance","run evals","variance analysis","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]