claude-brain 0.15.2 → 0.16.0

package/packs/meta/testing.json

@@ -1,172 +1,172 @@
-{
-  "id": "meta/testing",
-  "name": "Testing Best Practices",
-  "version": "1.0.0",
-  "stack": ["jest", "vitest", "mocha", "bun:test", "testing"],
-  "description": "Test pyramid, mocking strategies, anti-patterns, arrange-act-assert, and testing philosophy",
-  "author": "claude-brain",
-  "entries": [
-    {
-      "type": "best-practice",
-      "category": "Test Structure",
-      "title": "Follow Arrange-Act-Assert pattern",
-      "content": "Structure every test in three clear phases: Arrange (set up data and dependencies), Act (call the code under test), Assert (verify the result). This makes tests readable and consistent.",
-      "confidence": 0.95,
-      "tags": ["testing", "aaa", "structure"]
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Strategy",
-      "title": "Follow the testing pyramid",
-      "content": "Write many fast unit tests, fewer integration tests, and minimal E2E tests. Unit tests catch logic bugs cheaply. Integration tests verify component interaction. E2E tests validate critical user journeys.",
-      "confidence": 0.95,
-      "tags": ["testing", "pyramid", "strategy"]
-    },
-    {
-      "type": "anti-pattern",
-      "category": "Test Design",
-      "title": "Avoid testing implementation details",
-      "content": "Test behavior and outcomes, not internal implementation. Tests that verify private methods, internal state, or specific function calls break when refactoring even if behavior is unchanged.",
-      "confidence": 0.95,
-      "tags": ["testing", "behavior", "anti-pattern"]
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Design",
-      "title": "Each test should test one thing",
-      "content": "Keep tests focused on a single behavior or scenario. Multiple assertions are fine if they verify aspects of the same behavior. Avoid testing multiple unrelated behaviors in one test.",
-      "confidence": 0.9,
-      "tags": ["testing", "single-responsibility", "design"]
-    },
-    {
-      "type": "common-issue",
-      "category": "Mocking",
-      "title": "Don't over-mock",
-      "content": "Only mock external dependencies (APIs, databases, file system). Don't mock the code under test or internal modules. Over-mocking makes tests pass even when the real code is broken.",
-      "confidence": 0.9,
-      "tags": ["testing", "mocking", "integration"]
-    },
-    {
-      "type": "pattern",
-      "category": "Mocking",
-      "title": "Use dependency injection for mockable code",
-      "content": "Pass dependencies as parameters instead of importing them directly. This makes functions testable without module-level mocking, which is fragile and order-dependent.",
-      "confidence": 0.9,
-      "tags": ["testing", "mocking", "dependency-injection"]
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Design",
-      "title": "Write descriptive test names",
-      "content": "Test names should describe the scenario and expected outcome: 'should return 404 when user does not exist' is better than 'test getUser'. Good names serve as documentation.",
-      "confidence": 0.9,
-      "tags": ["testing", "naming", "documentation"]
-    },
-    {
-      "type": "anti-pattern",
-      "category": "Test Design",
-      "title": "Avoid test interdependence",
-      "content": "Each test must be independent and able to run in isolation. Never rely on test execution order or shared mutable state between tests. Use beforeEach to reset state.",
-      "confidence": 0.95,
-      "tags": ["testing", "isolation", "anti-pattern"]
-    },
-    {
-      "type": "common-issue",
-      "category": "Async Testing",
-      "title": "Always await async assertions",
-      "content": "Forgetting to await async operations in tests causes false positives — the test passes before assertions run. Always return or await promises, and use the test framework's async utilities.",
-      "confidence": 0.9,
-      "tags": ["testing", "async", "promises"]
-    },
-    {
-      "type": "pattern",
-      "category": "Test Data",
-      "title": "Use factories for test data",
-      "content": "Create factory functions that generate test data with sensible defaults and overrides. This reduces boilerplate, keeps tests focused on what's relevant, and makes it easy to create variations.",
-      "confidence": 0.85,
-      "tags": ["testing", "data", "factories"],
-      "example": "function createUser(overrides = {}) { return { name: 'Test', email: 'test@test.com', ...overrides } }"
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Maintenance",
-      "title": "Keep tests fast",
-      "content": "Fast tests get run often. Avoid real network calls, file I/O, and sleeps in unit tests. Use in-memory alternatives and mock external services. A slow test suite leads to developers skipping tests.",
-      "confidence": 0.9,
-      "tags": ["testing", "performance", "speed"]
-    },
-    {
-      "type": "anti-pattern",
-      "category": "Test Design",
-      "title": "Avoid snapshot overuse",
-      "content": "Snapshot tests are easy to write but hard to maintain. Large snapshots are never reviewed when updated. Use snapshots sparingly for stable output (serialized data, error messages), not for entire component trees.",
-      "confidence": 0.85,
-      "tags": ["testing", "snapshots", "anti-pattern"]
-    },
-    {
-      "type": "pattern",
-      "category": "Error Testing",
-      "title": "Test error cases and edge cases",
-      "content": "Don't only test the happy path. Test invalid input, empty data, null values, boundary conditions, and error responses. Error handling code has bugs too — verify it works correctly.",
-      "confidence": 0.9,
-      "tags": ["testing", "error-cases", "edge-cases"]
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Strategy",
-      "title": "Use integration tests for API endpoints",
-      "content": "Test API endpoints with real HTTP requests against the actual server (with mocked external services). This verifies routing, middleware, validation, and response formatting together.",
-      "confidence": 0.85,
-      "tags": ["testing", "integration", "api"]
-    },
-    {
-      "type": "common-issue",
-      "category": "Mocking",
-      "title": "Reset mocks between tests",
-      "content": "Always clear mock state between tests using beforeEach, afterEach, or the framework's auto-clear feature. Leftover mock state from previous tests causes intermittent failures.",
-      "confidence": 0.9,
-      "tags": ["testing", "mocking", "cleanup"]
-    },
-    {
-      "type": "anti-pattern",
-      "category": "Test Design",
-      "title": "Avoid conditional logic in tests",
-      "content": "Tests should not contain if/else, loops, or try/catch. Each test should follow a straight-line path. If you need different scenarios, write separate tests for each.",
-      "confidence": 0.9,
-      "tags": ["testing", "simplicity", "anti-pattern"]
-    },
-    {
-      "type": "best-practice",
-      "category": "Coverage",
-      "title": "Use coverage as a guide, not a goal",
-      "content": "Code coverage measures lines executed, not quality of assertions. 100% coverage with weak assertions is worse than 80% coverage with thorough behavior tests. Focus on testing critical paths well.",
-      "confidence": 0.9,
-      "tags": ["testing", "coverage", "quality"]
-    },
-    {
-      "type": "pattern",
-      "category": "Test Organization",
-      "title": "Group tests by behavior with describe blocks",
-      "content": "Use nested describe blocks to group related tests: by function/method, then by scenario. This creates readable test output and makes it easy to find and run specific test groups.",
-      "confidence": 0.85,
-      "tags": ["testing", "organization", "describe"],
-      "example": "describe('UserService', () => {\n  describe('createUser', () => {\n    it('should create with valid data', ...)\n    it('should reject duplicate email', ...)\n  })\n})"
-    },
-    {
-      "type": "best-practice",
-      "category": "Test Design",
-      "title": "Assert on the most specific thing",
-      "content": "Use the most specific assertion available. `toBe(3)` is better than `toBeGreaterThan(0)`. `toEqual({name: 'test'})` is better than `toBeTruthy()`. Specific assertions catch bugs that general ones miss.",
-      "confidence": 0.85,
-      "tags": ["testing", "assertions", "specificity"]
-    },
-    {
-      "type": "common-issue",
-      "category": "Flaky Tests",
-      "title": "Eliminate time-dependent tests",
-      "content": "Tests that depend on wall clock time, setTimeout delays, or Date.now() are inherently flaky. Use fake timers (jest.useFakeTimers, vi.useFakeTimers) to control time in tests.",
-      "confidence": 0.9,
-      "tags": ["testing", "flaky", "timers"]
-    }
-  ]
-}
+{
+  "id": "meta/testing",
+  "name": "Testing Best Practices",
+  "version": "1.0.0",
+  "stack": ["jest", "vitest", "mocha", "bun:test", "testing"],
+  "description": "Test pyramid, mocking strategies, anti-patterns, arrange-act-assert, and testing philosophy",
+  "author": "claude-brain",
+  "entries": [
+    {
+      "type": "best-practice",
+      "category": "Test Structure",
+      "title": "Follow Arrange-Act-Assert pattern",
+      "content": "Structure every test in three clear phases: Arrange (set up data and dependencies), Act (call the code under test), Assert (verify the result). This makes tests readable and consistent.",
+      "confidence": 0.95,
+      "tags": ["testing", "aaa", "structure"]
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Strategy",
+      "title": "Follow the testing pyramid",
+      "content": "Write many fast unit tests, fewer integration tests, and minimal E2E tests. Unit tests catch logic bugs cheaply. Integration tests verify component interaction. E2E tests validate critical user journeys.",
+      "confidence": 0.95,
+      "tags": ["testing", "pyramid", "strategy"]
+    },
+    {
+      "type": "anti-pattern",
+      "category": "Test Design",
+      "title": "Avoid testing implementation details",
+      "content": "Test behavior and outcomes, not internal implementation. Tests that verify private methods, internal state, or specific function calls break when refactoring even if behavior is unchanged.",
+      "confidence": 0.95,
+      "tags": ["testing", "behavior", "anti-pattern"]
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Design",
+      "title": "Each test should test one thing",
+      "content": "Keep tests focused on a single behavior or scenario. Multiple assertions are fine if they verify aspects of the same behavior. Avoid testing multiple unrelated behaviors in one test.",
+      "confidence": 0.9,
+      "tags": ["testing", "single-responsibility", "design"]
+    },
+    {
+      "type": "common-issue",
+      "category": "Mocking",
+      "title": "Don't over-mock",
+      "content": "Only mock external dependencies (APIs, databases, file system). Don't mock the code under test or internal modules. Over-mocking makes tests pass even when the real code is broken.",
+      "confidence": 0.9,
+      "tags": ["testing", "mocking", "integration"]
+    },
+    {
+      "type": "pattern",
+      "category": "Mocking",
+      "title": "Use dependency injection for mockable code",
+      "content": "Pass dependencies as parameters instead of importing them directly. This makes functions testable without module-level mocking, which is fragile and order-dependent.",
+      "confidence": 0.9,
+      "tags": ["testing", "mocking", "dependency-injection"]
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Design",
+      "title": "Write descriptive test names",
+      "content": "Test names should describe the scenario and expected outcome: 'should return 404 when user does not exist' is better than 'test getUser'. Good names serve as documentation.",
+      "confidence": 0.9,
+      "tags": ["testing", "naming", "documentation"]
+    },
+    {
+      "type": "anti-pattern",
+      "category": "Test Design",
+      "title": "Avoid test interdependence",
+      "content": "Each test must be independent and able to run in isolation. Never rely on test execution order or shared mutable state between tests. Use beforeEach to reset state.",
+      "confidence": 0.95,
+      "tags": ["testing", "isolation", "anti-pattern"]
+    },
+    {
+      "type": "common-issue",
+      "category": "Async Testing",
+      "title": "Always await async assertions",
+      "content": "Forgetting to await async operations in tests causes false positives — the test passes before assertions run. Always return or await promises, and use the test framework's async utilities.",
+      "confidence": 0.9,
+      "tags": ["testing", "async", "promises"]
+    },
+    {
+      "type": "pattern",
+      "category": "Test Data",
+      "title": "Use factories for test data",
+      "content": "Create factory functions that generate test data with sensible defaults and overrides. This reduces boilerplate, keeps tests focused on what's relevant, and makes it easy to create variations.",
+      "confidence": 0.85,
+      "tags": ["testing", "data", "factories"],
+      "example": "function createUser(overrides = {}) { return { name: 'Test', email: 'test@test.com', ...overrides } }"
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Maintenance",
+      "title": "Keep tests fast",
+      "content": "Fast tests get run often. Avoid real network calls, file I/O, and sleeps in unit tests. Use in-memory alternatives and mock external services. A slow test suite leads to developers skipping tests.",
+      "confidence": 0.9,
+      "tags": ["testing", "performance", "speed"]
+    },
+    {
+      "type": "anti-pattern",
+      "category": "Test Design",
+      "title": "Avoid snapshot overuse",
+      "content": "Snapshot tests are easy to write but hard to maintain. Large snapshots are never reviewed when updated. Use snapshots sparingly for stable output (serialized data, error messages), not for entire component trees.",
+      "confidence": 0.85,
+      "tags": ["testing", "snapshots", "anti-pattern"]
+    },
+    {
+      "type": "pattern",
+      "category": "Error Testing",
+      "title": "Test error cases and edge cases",
+      "content": "Don't only test the happy path. Test invalid input, empty data, null values, boundary conditions, and error responses. Error handling code has bugs too — verify it works correctly.",
+      "confidence": 0.9,
+      "tags": ["testing", "error-cases", "edge-cases"]
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Strategy",
+      "title": "Use integration tests for API endpoints",
+      "content": "Test API endpoints with real HTTP requests against the actual server (with mocked external services). This verifies routing, middleware, validation, and response formatting together.",
+      "confidence": 0.85,
+      "tags": ["testing", "integration", "api"]
+    },
+    {
+      "type": "common-issue",
+      "category": "Mocking",
+      "title": "Reset mocks between tests",
+      "content": "Always clear mock state between tests using beforeEach, afterEach, or the framework's auto-clear feature. Leftover mock state from previous tests causes intermittent failures.",
+      "confidence": 0.9,
+      "tags": ["testing", "mocking", "cleanup"]
+    },
+    {
+      "type": "anti-pattern",
+      "category": "Test Design",
+      "title": "Avoid conditional logic in tests",
+      "content": "Tests should not contain if/else, loops, or try/catch. Each test should follow a straight-line path. If you need different scenarios, write separate tests for each.",
+      "confidence": 0.9,
+      "tags": ["testing", "simplicity", "anti-pattern"]
+    },
+    {
+      "type": "best-practice",
+      "category": "Coverage",
+      "title": "Use coverage as a guide, not a goal",
+      "content": "Code coverage measures lines executed, not quality of assertions. 100% coverage with weak assertions is worse than 80% coverage with thorough behavior tests. Focus on testing critical paths well.",
+      "confidence": 0.9,
+      "tags": ["testing", "coverage", "quality"]
+    },
+    {
+      "type": "pattern",
+      "category": "Test Organization",
+      "title": "Group tests by behavior with describe blocks",
+      "content": "Use nested describe blocks to group related tests: by function/method, then by scenario. This creates readable test output and makes it easy to find and run specific test groups.",
+      "confidence": 0.85,
+      "tags": ["testing", "organization", "describe"],
+      "example": "describe('UserService', () => {\n  describe('createUser', () => {\n    it('should create with valid data', ...)\n    it('should reject duplicate email', ...)\n  })\n})"
+    },
+    {
+      "type": "best-practice",
+      "category": "Test Design",
+      "title": "Assert on the most specific thing",
+      "content": "Use the most specific assertion available. `toBe(3)` is better than `toBeGreaterThan(0)`. `toEqual({name: 'test'})` is better than `toBeTruthy()`. Specific assertions catch bugs that general ones miss.",
+      "confidence": 0.85,
+      "tags": ["testing", "assertions", "specificity"]
+    },
+    {
+      "type": "common-issue",
+      "category": "Flaky Tests",
+      "title": "Eliminate time-dependent tests",
+      "content": "Tests that depend on wall clock time, setTimeout delays, or Date.now() are inherently flaky. Use fake timers (jest.useFakeTimers, vi.useFakeTimers) to control time in tests.",
+      "confidence": 0.9,
+      "tags": ["testing", "flaky", "timers"]
+    }
+  ]
+}