[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZ0P104PXMW2GAVTGYNDY2":3,"skill-same:01M6WZ0P104PXMW2GAVTGYNDY2":78},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6WZ0P104PXMW2GAVTGYNDY2","testing-strategy",null,"Testing approach — unit vs integration vs E2E, coverage goals, organization. Use when deciding what to test, choosing between unit\u002Fintegration\u002FE2E tests, planning a test strategy for new functionality, or setting coverage goals.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftesting-strategy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"testing strategy","strategy","testing","use","when","for","v1","unit","tests","organization","goals","test strategy","coverage","work","e2e","engineering","integration","planning","e2e tests","test","2026-11-10 10:12:30",false,"---\nname: testing-strategy\ndescription: |\n  Testing approach — unit vs integration vs E2E, coverage goals, organization. Use when deciding what to test, choosing between unit\u002Fintegration\u002FE2E tests, planning a test strategy for new functionality, or setting coverage goals.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-testing-strategy\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n    layer: 3\n---\n\n# Testing Strategy\n\n## Intro\n\nPick the cheapest test that gives you confidence the code is\ncorrect. Many fast unit tests, fewer integration tests, and a thin\nlayer of end-to-end tests for the critical paths — that is the\ntesting pyramid, and it still works.\n\n## Overview\n\n### Match the test type to the code\n\n- **Pure logic** (calculations, transformations) → unit tests.\n- **Integration points** (database, HTTP API, file I\u002FO) →\n  integration tests.\n- **User workflows** (end-to-end paths) → E2E tests.\n\n### Apply the testing pyramid\n\n- Many unit tests — fast, isolated, cheap to run on every commit.\n- Fewer integration tests — slower, exercise the boundary between\n  your code and external systems.\n- Minimal E2E tests — slowest and most flaky, reserved for the\n  critical happy paths a user must be able to complete.\n\n### Naming and shape\n\nName tests `test_\u003Cfunction>_\u003Cscenario>_\u003Cexpected_result>` so\nfailures self-document. Each test follows the AAA pattern:\n**Arrange** the inputs, **Act** by calling the unit, **Assert**\nthe expected outcome. One logical assertion per test where\npractical.\n\n### Prioritize what you test\n\n- Error paths and edge cases over happy paths\n- Public API over internal implementation details\n- Complex branching logic over trivial getters\u002Fsetters\n\n### Coverage as a smoke alarm\n\nAim for ~80% coverage on business logic. Do not chase 100%\neverywhere — coverage is a smoke alarm, not a goal. The last 20%\nis usually trivial code, generated code, or defensive paths that\ncost more to test than they save.\n\n### Example\n\nUser says: \"I added a new `calculate_discount()` function, what\ntests do I need?\" The agent recommends:\n\n- `test_calculate_discount_percentage_applied_correctly`\n- `test_calculate_discount_zero_amount_returns_zero`\n- `test_calculate_discount_negative_amount_returns_error`\n- `test_calculate_discount_exceeds_max_caps_at_limit`\n\nOne happy path, one boundary, one error case, one limit case.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Testing implementation details (private methods, internal state).** Tests that verify internals couple the test suite to the implementation — any structural change breaks tests even when behavior is correct. Test through the public API at the appropriate level.\n- **Slow unit tests that hit disk or network.** A unit test that opens a file, makes an HTTP call, or connects to a database is an integration test with a misleading name. It will be slow and flaky in CI. Mock or stub at the boundary; keep unit tests pure.\n- **E2E tests for every code path.** E2E tests are expensive to write, slow to run, and flaky to maintain. They should cover the critical user journeys that must work — not every conditional branch. Those belong in unit and integration tests.\n- **Coverage goals as the only quality metric.** 100% line coverage with assertions that never fail (e.g. `assert True`) provides zero confidence. Coverage is a smoke alarm — it tells you what was executed, not whether the behavior was verified.\n- **No test for the unhappy path.** Error cases and edge cases are where bugs live. Happy-path-only tests give false confidence. For every behavior, consider: what happens with empty input, invalid input, a missing dependency, a limit exceeded?\n- **Deviating from the testing pyramid without understanding the trade-offs.** If the test suite is inverted (mostly E2E) or trophy-shaped (mostly integration), that may be appropriate for the architecture — but it should be a deliberate decision with documented trade-offs, not an accident.\n- **Tests that pass when the production code is deleted.** A test suite that stays green after the module is removed was not testing anything. Run a mutation test or delete the module temporarily to verify the suite would actually catch a regression.\n\n## Full reference\n\n### Choosing the right level\n\n| Question | Right test level |\n|---|---|\n| Does this pure function compute the right value? | Unit |\n| Does this query return the right rows from the DB? | Integration |\n| Does this HTTP endpoint persist and respond correctly? | Integration |\n| Can a user complete checkout end-to-end? | E2E |\n| Does this private helper handle edge case X? | Test through the public API, not directly |\n\n### When to break the pyramid\n\n- **Inverted pyramid (lots of E2E):** the system has weak\n  internal seams; integration tests would be more valuable but\n  the architecture makes them hard. Refactor for testability.\n- **Trophy shape (heavy integration):** typical for thin services\n  where most logic is glue between external systems; the unit\n  layer is genuinely small.\n- **Diamond (heavy integration, light unit and E2E):** common for\n  microservices that mostly orchestrate.\n\nThe pyramid is a default, not a law.\n\n### Anti-patterns\n\n- Testing implementation details (e.g., asserting on private\n  method calls) — couples tests to refactoring\n- Slow unit tests because they hit the disk or network\n- E2E tests that exercise every code path instead of critical\n  flows\n- Coverage goals as the only quality metric\n- Tests that pass when the production code is deleted (they\n  weren't testing anything)\n- Skipping tests for \"trivial\" code that turns out to be wrong\n","# Testing Strategy\n\n## Intro\n\nPick the cheapest test that gives you confidence the code is\ncorrect. Many fast unit tests, fewer integration tests, and a thin\nlayer of end-to-end tests for the critical paths — that is the\ntesting pyramid, and it still works.\n\n## Overview\n\n### Match the test type to the code\n\n- **Pure logic** (calculations, transformations) → unit tests.\n- **Integration points** (database, HTTP API, file I\u002FO) →\n  integration tests.\n- **User workflows** (end-to-end paths) → E2E tests.\n\n### Apply the testing pyramid\n\n- Many unit tests — fast, isolated, cheap to run on every commit.\n- Fewer integration tests — slower, exercise the boundary between\n  your code and external systems.\n- Minimal E2E tests — slowest and most flaky, reserved for the\n  critical happy paths a user must be able to complete.\n\n### Naming and shape\n\nName tests `test_\u003Cfunction>_\u003Cscenario>_\u003Cexpected_result>` so\nfailures self-document. Each test follows the AAA pattern:\n**Arrange** the inputs, **Act** by calling the unit, **Assert**\nthe expected outcome. One logical assertion per test where\npractical.\n\n### Prioritize what you test\n\n- Error paths and edge cases over happy paths\n- Public API over internal implementation details\n- Complex branching logic over trivial getters\u002Fsetters\n\n### Coverage as a smoke alarm\n\nAim for ~80% coverage on business logic. Do not chase 100%\neverywhere — coverage is a smoke alarm, not a goal. The last 20%\nis usually trivial code, generated code, or defensive paths that\ncost more to test than they save.\n\n### Example\n\nUser says: \"I added a new `calculate_discount()` function, what\ntests do I need?\" The agent recommends:\n\n- `test_calculate_discount_percentage_applied_correctly`\n- `test_calculate_discount_zero_amount_returns_zero`\n- `test_calculate_discount_negative_amount_returns_error`\n- `test_calculate_discount_exceeds_max_caps_at_limit`\n\nOne happy path, one boundary, one error case, one limit case.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Testing implementation details (private methods, internal state).** Tests that verify internals couple the test suite to the implementation — any structural change breaks tests even when behavior is correct. Test through the public API at the appropriate level.\n- **Slow unit tests that hit disk or network.** A unit test that opens a file, makes an HTTP call, or connects to a database is an integration test with a misleading name. It will be slow and flaky in CI. Mock or stub at the boundary; keep unit tests pure.\n- **E2E tests for every code path.** E2E tests are expensive to write, slow to run, and flaky to maintain. They should cover the critical user journeys that must work — not every conditional branch. Those belong in unit and integration tests.\n- **Coverage goals as the only quality metric.** 100% line coverage with assertions that never fail (e.g. `assert True`) provides zero confidence. Coverage is a smoke alarm — it tells you what was executed, not whether the behavior was verified.\n- **No test for the unhappy path.** Error cases and edge cases are where bugs live. Happy-path-only tests give false confidence. For every behavior, consider: what happens with empty input, invalid input, a missing dependency, a limit exceeded?\n- **Deviating from the testing pyramid without understanding the trade-offs.** If the test suite is inverted (mostly E2E) or trophy-shaped (mostly integration), that may be appropriate for the architecture — but it should be a deliberate decision with documented trade-offs, not an accident.\n- **Tests that pass when the production code is deleted.** A test suite that stays green after the module is removed was not testing anything. Run a mutation test or delete the module temporarily to verify the suite would actually catch a regression.\n\n## Full reference\n\n### Choosing the right level\n\n| Question | Right test level |\n|---|---|\n| Does this pure function compute the right value? | Unit |\n| Does this query return the right rows from the DB? | Integration |\n| Does this HTTP endpoint persist and respond correctly? | Integration |\n| Can a user complete checkout end-to-end? | E2E |\n| Does this private helper handle edge case X? | Test through the public API, not directly |\n\n### When to break the pyramid\n\n- **Inverted pyramid (lots of E2E):** the system has weak\n  internal seams; integration tests would be more valuable but\n  the architecture makes them hard. Refactor for testability.\n- **Trophy shape (heavy integration):** typical for thin services\n  where most logic is glue between external systems; the unit\n  layer is genuinely small.\n- **Diamond (heavy integration, light unit and E2E):** common for\n  microservices that mostly orchestrate.\n\nThe pyramid is a default, not a law.\n\n### Anti-patterns\n\n- Testing implementation details (e.g., asserting on private\n  method calls) — couples tests to refactoring\n- Slow unit tests because they hit the disk or network\n- E2E tests that exercise every code path instead of critical\n  flows\n- Coverage goals as the only quality metric\n- Tests that pass when the production code is deleted (they\n  weren't testing anything)\n- Skipping tests for \"trivial\" code that turns out to be wrong\n",{"name":5,"metadata":49,"description":56},{"processkit":50},{"id":51,"layer":52,"created":53,"version":54,"category":39,"apiVersion":55},"SKILL-testing-strategy",3,1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","Testing approach — unit vs integration vs E2E, coverage goals, organization. Use when deciding what to test, choosing between unit\u002Fintegration\u002FE2E tests, planning a test strategy for new functionality, or setting coverage goals.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftesting-strategy","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add projectious-work\u002Fprocesskit --skill testing-strategy",{"tool":70,"command":71},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill testing-strategy",{"tool":73,"command":74},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill testing-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.17.0\u002Fcontext\u002Fskills\u002Fengineering\u002Ftesting-strategy\u002FSKILL.md",true,[],[79,103,123,144,161,179],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":44},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[89,90,91,92,93,94,37,95,96,97,81,98,99,100,30,101,102],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":44},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[109],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,111,112,113,114,115,94,37,116,117,96,118,119,120,98,121,122],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":44},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[89,130,131,91,92,132,94,37,133,134,135,136,98,137,138,139,140,141,142,143],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":44},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[89,97,151,91,94,152,153,116,154,133,96,155,156,98,157,158,138,159,30,160],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":44},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[168,169,170,171,94,172,173,174,37,175,176,177,178],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":44},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[89,186,187,91,92,132,94,152,37,95,133,188,96,135,98,158,138,139,189,102],"capability","capability management","queries","changes"]