[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BQQDNKDKBQ7XSWH4PPBCPC":3,"skill-same:01M7BQQDNKDKBQ7XSWH4PPBCPC":45},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":6,"ownerHtmlUrl":29,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":30,"install":31,"resources":44},"01M7BQQDNKDKBQ7XSWH4PPBCPC","testing-python",null,"Write and evaluate effective Python tests using pytest. Use when writing tests, reviewing test code, debugging test failures, or improving test coverage. Covers test design, fixtures, parameterization, mocking, and async testing.","linyouxue\u002Fskill-repair-benchmark","linyouxue","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F216151464?v=4","01M7BJEVCXKD74KH6FG9CBVSQB","林宥学","01M7BJEVE02NP217V93BKZFC0J",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fevaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Ffix-build-agentops\u002Fskills\u002Ftesting-python\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: testing-python\ndescription: Write and evaluate effective Python tests using pytest. Use when writing tests, reviewing test code, debugging test failures, or improving test coverage. Covers test design, fixtures, parameterization, mocking, and async testing.\n---\n\n# Writing Effective Python Tests\n\n## Core Principles\n\nEvery test should be **atomic**, **self-contained**, and test **single functionality**. A test that tests multiple things is harder to debug and maintain.\n\n## Test Structure\n\n### Atomic unit tests\n\nEach test should verify a single behavior. The test name should tell you what's broken when it fails. Multiple assertions are fine when they all verify the same behavior.\n\n```python\n# Good: Name tells you what's broken\ndef test_user_creation_sets_defaults():\n    user = User(name=\"Alice\")\n    assert user.role == \"member\"\n    assert user.id is not None\n    assert user.created_at is not None\n```\n\n### Use parameterization for variations of the same concept\n\n```python\nimport pytest\n\n@pytest.mark.parametrize(\"input,expected\", [\n    (\"hello\", \"HELLO\"),\n    (\"World\", \"WORLD\"),\n    (\"\", \"\"),\n    (\"123\", \"123\"),\n])\ndef test_uppercase_conversion(input, expected):\n    assert input.upper() == expected\n```\n\n### Use separate tests for different functionality\n\nDon't parameterize unrelated behaviors. If the test logic differs, write separate tests.\n\n## Project-Specific Rules\n\n### No async markers needed\n\nThis project uses `asyncio_mode = \"auto\"` globally. Write async tests without decorators:\n\n```python\nasync def test_async_operation():\n    result = await some_async_function()\n    assert result == expected\n```\n\n### Imports at module level\n\nPut imports at the top of the file unless the project explicitly requires a delayed import.\n\n### Use in-memory transport for testing\n\nMock external boundaries rather than internal code when isolation is required.\n\n## Running Tests\n\n```bash\nuv run pytest -n auto\nuv run pytest -n auto -x\nuv run pytest path\u002Fto\u002Ftest.py\nuv run pytest -k \"test_name\"\nuv run pytest -m \"not integration\"\n```\n\n## Regression Gate for Stateful SDK Repairs\n\nFor packages with module-level clients, singletons, sessions, workers, decorators, request queues, mutable event objects, or other process-shared state, a test that passes alone can still fail in sequence. Treat order sensitivity as diagnostic evidence, not as proof that global lifecycle construction is itself wrong.\n\n1. Record the authoritative baseline before editing: exact failing node IDs, pass\u002Ffail counts, exception classes, and the assertion contract. If the original suite is already at `9 passed, 1 failed`, preserve that state as the minimum acceptable regression baseline until the remaining failure is fixed.\n2. Reproduce one failing test in isolation, then run the containing module and the full configured suite. A fix is not accepted if it repairs one assertion while creating a new failure or error elsewhere.\n3. If isolated and suite results differ, build a lifecycle table for uninitialized, active, ended, and reused states. Inspect singleton instances, ended sessions, cached configuration, accumulated tags, background workers, request history, and mutable objects. However, **sequence dependence only proves that shared state influences the symptom; it does not prove that singleton identity, cache reset policy, or object reconstruction is the repair target.**\n4. Start from the failing assertion's owning object and transition. For assertions about timestamps, completion flags, statuses, result values, mutation, or serialization, inspect that object's initialization semantics and the code path that updates it before changing process-global lifecycle behavior.\n5. Preserve the public lifecycle contract at the module boundary. Trace `init`, `start_session`, `record`, decorators, `end_session`, and teardown through the existing singleton semantics. Do not change singleton creation\u002Freuse semantics merely to make one test start from a fresh object unless the API contract and authoritative failure evidence specifically require that behavior.\n6. Treat changes to singleton identity, cache construction, automatic restart, or global reset behavior as high-risk. Immediately run the full relevant suite after such a candidate. If it creates a new exception class, a new failing node, or fewer passing tests, revert it before investigating anything else.\n7. Use a minimal state-transition fix at the component that owns the violated contract. Prefer correcting the object's initialization\u002Fupdate semantics over broad packaging, dependency, fixture, or lifecycle changes when the failure is a field-transition assertion.\n8. After every candidate patch, compare the exact failure set with the last-known-good snapshot. Restore a regression before trying the next hypothesis instead of stacking more changes onto it. Never patch a newly introduced regression while retaining the candidate that caused it.\n9. Run the exact project command under the dependency constraints and environment used by CI. Isolated tests are diagnostic evidence; completion requires the full authoritative suite to pass in the runtimes actually exercised by the benchmark.\n\n### Stateful failure decision rule\n\nUse this order before modifying global lifecycle code:\n\n1. What exact assertion failed?\n2. Which object owns the asserted field\u002Fbehavior?\n3. What should that object's state be at construction?\n4. Which operation is supposed to transition that state?\n5. Does the failure reproduce without changing singleton\u002Fcache identity?\n6. Only if the contract itself requires a new\u002Freinitialized global object should singleton\u002Freset semantics be changed.\n\n## Checklist\n\nBefore submitting a repair:\n- [ ] Baseline failing node IDs and counts recorded\n- [ ] Exact failing assertion understood\n- [ ] Narrow test rerun after each candidate\n- [ ] Full relevant suite rerun after each candidate\n- [ ] No newly introduced failing node or exception class retained\n- [ ] Global singleton\u002Fcache semantics unchanged unless directly justified\n- [ ] Final patch corresponds exactly to the working tree that passed\n","# Writing Effective Python Tests\n\n## Core Principles\n\nEvery test should be **atomic**, **self-contained**, and test **single functionality**. A test that tests multiple things is harder to debug and maintain.\n\n## Test Structure\n\n### Atomic unit tests\n\nEach test should verify a single behavior. The test name should tell you what's broken when it fails. Multiple assertions are fine when they all verify the same behavior.\n\n```python\n# Good: Name tells you what's broken\ndef test_user_creation_sets_defaults():\n    user = User(name=\"Alice\")\n    assert user.role == \"member\"\n    assert user.id is not None\n    assert user.created_at is not None\n```\n\n### Use parameterization for variations of the same concept\n\n```python\nimport pytest\n\n@pytest.mark.parametrize(\"input,expected\", [\n    (\"hello\", \"HELLO\"),\n    (\"World\", \"WORLD\"),\n    (\"\", \"\"),\n    (\"123\", \"123\"),\n])\ndef test_uppercase_conversion(input, expected):\n    assert input.upper() == expected\n```\n\n### Use separate tests for different functionality\n\nDon't parameterize unrelated behaviors. If the test logic differs, write separate tests.\n\n## Project-Specific Rules\n\n### No async markers needed\n\nThis project uses `asyncio_mode = \"auto\"` globally. Write async tests without decorators:\n\n```python\nasync def test_async_operation():\n    result = await some_async_function()\n    assert result == expected\n```\n\n### Imports at module level\n\nPut imports at the top of the file unless the project explicitly requires a delayed import.\n\n### Use in-memory transport for testing\n\nMock external boundaries rather than internal code when isolation is required.\n\n## Running Tests\n\n```bash\nuv run pytest -n auto\nuv run pytest -n auto -x\nuv run pytest path\u002Fto\u002Ftest.py\nuv run pytest -k \"test_name\"\nuv run pytest -m \"not integration\"\n```\n\n## Regression Gate for Stateful SDK Repairs\n\nFor packages with module-level clients, singletons, sessions, workers, decorators, request queues, mutable event objects, or other process-shared state, a test that passes alone can still fail in sequence. Treat order sensitivity as diagnostic evidence, not as proof that global lifecycle construction is itself wrong.\n\n1. Record the authoritative baseline before editing: exact failing node IDs, pass\u002Ffail counts, exception classes, and the assertion contract. If the original suite is already at `9 passed, 1 failed`, preserve that state as the minimum acceptable regression baseline until the remaining failure is fixed.\n2. Reproduce one failing test in isolation, then run the containing module and the full configured suite. A fix is not accepted if it repairs one assertion while creating a new failure or error elsewhere.\n3. If isolated and suite results differ, build a lifecycle table for uninitialized, active, ended, and reused states. Inspect singleton instances, ended sessions, cached configuration, accumulated tags, background workers, request history, and mutable objects. However, **sequence dependence only proves that shared state influences the symptom; it does not prove that singleton identity, cache reset policy, or object reconstruction is the repair target.**\n4. Start from the failing assertion's owning object and transition. For assertions about timestamps, completion flags, statuses, result values, mutation, or serialization, inspect that object's initialization semantics and the code path that updates it before changing process-global lifecycle behavior.\n5. Preserve the public lifecycle contract at the module boundary. Trace `init`, `start_session`, `record`, decorators, `end_session`, and teardown through the existing singleton semantics. Do not change singleton creation\u002Freuse semantics merely to make one test start from a fresh object unless the API contract and authoritative failure evidence specifically require that behavior.\n6. Treat changes to singleton identity, cache construction, automatic restart, or global reset behavior as high-risk. Immediately run the full relevant suite after such a candidate. If it creates a new exception class, a new failing node, or fewer passing tests, revert it before investigating anything else.\n7. Use a minimal state-transition fix at the component that owns the violated contract. Prefer correcting the object's initialization\u002Fupdate semantics over broad packaging, dependency, fixture, or lifecycle changes when the failure is a field-transition assertion.\n8. After every candidate patch, compare the exact failure set with the last-known-good snapshot. Restore a regression before trying the next hypothesis instead of stacking more changes onto it. Never patch a newly introduced regression while retaining the candidate that caused it.\n9. Run the exact project command under the dependency constraints and environment used by CI. Isolated tests are diagnostic evidence; completion requires the full authoritative suite to pass in the runtimes actually exercised by the benchmark.\n\n### Stateful failure decision rule\n\nUse this order before modifying global lifecycle code:\n\n1. What exact assertion failed?\n2. Which object owns the asserted field\u002Fbehavior?\n3. What should that object's state be at construction?\n4. Which operation is supposed to transition that state?\n5. Does the failure reproduce without changing singleton\u002Fcache identity?\n6. Only if the contract itself requires a new\u002Freinitialized global object should singleton\u002Freset semantics be changed.\n\n## Checklist\n\nBefore submitting a repair:\n- [ ] Baseline failing node IDs and counts recorded\n- [ ] Exact failing assertion understood\n- [ ] Narrow test rerun after each candidate\n- [ ] Full relevant suite rerun after each candidate\n- [ ] No newly introduced failing node or exception class retained\n- [ ] Global singleton\u002Fcache semantics unchanged unless directly justified\n- [ ] Final patch corresponds exactly to the working tree that passed\n",{"name":5,"description":7},"main","cdcb6d230f3b15c3c33f8a2bdd16439f43602cbe","evaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Ffix-build-agentops\u002Fskills\u002Ftesting-python",1,"https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark","https:\u002F\u002Fgithub.com\u002Flinyouxue","2026-11-14 20:28:35",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add linyouxue\u002Fskill-repair-benchmark --skill testing-python",{"tool":37,"command":38},"bunx","bunx skills add linyouxue\u002Fskill-repair-benchmark --skill testing-python",{"tool":40,"command":41},"pnpm","pnpm dlx skills add linyouxue\u002Fskill-repair-benchmark --skill testing-python","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fevaluation\u002Fdata\u002Fskillsbench87\u002Freferences\u002Ffix-build-agentops\u002Fskills\u002Ftesting-python\u002FSKILL.md",true,[],[46,53,60,67,72,77],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":50,"categories":51,"keywords":52,"publishedAt":19},"01M7E1HGVRY73NBJ022CJG13X6","video-frame-extraction","Extract frames from video files and save them as images using OpenCV","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":54,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":59,"publishedAt":19},"01M7E1HAG5R7CJ9C8NYJS771MB","openai-vision","Analyze images and multi-frame sequences using OpenAI GPT vision models","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":19},"01M7E1H7DADKB6QBWKC2KQ63SZ","image-ocr","Extract text content from images using Tesseract OCR via Python, including structured field extraction from receipts and forms","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_03\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[],{"skillNo":68,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M7E1H0WBNT43TENGQY7AVZHD","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fvideo-frame-extraction\u002FSKILL.md",[],[],{"skillNo":73,"name":55,"nameZh":6,"description":56,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7E1GTC7D4N4Q2EF03875J9E","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fopenai-vision\u002FSKILL.md",[],[],{"skillNo":78,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M7E1GQ92CWFMGH53KSSE4WER","https:\u002F\u002Fgithub.com\u002Flinyouxue\u002Fskill-repair-benchmark\u002Fblob\u002Fmain\u002Fjpg-ocr-stat\u002Fresult\u002Fskilltta-claude4.7\u002Fgroup_03\u002Frun_02\u002Finputs\u002Fskills\u002Fimage-ocr\u002FSKILL.md",[],[]]