一键导入
testing
Unit test authoring and coverage checking for Canvas plugins
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Unit test authoring and coverage checking for Canvas plugins
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | testing |
| description | Unit test authoring and coverage checking for Canvas plugins |
This skill provides guidance for writing unit tests and checking coverage for Canvas plugins.
Use this skill when:
These rules are non-negotiable. Follow them exactly.
CRITICAL: The tests/ directory MUST be at the container level (parallel to the inner plugin folder), NOT inside the inner folder.
my-plugin-name/ # Container folder (kebab-case)
├── pyproject.toml # Container level
├── tests/ # Container level - NOT inside inner folder!
│ ├── conftest.py
│ ├── handlers/
│ │ ├── test_vitals_handler.py # mirrors inner/handlers/vitals_handler.py
│ │ └── test_lab_handler.py # mirrors inner/handlers/lab_handler.py
│ ├── api/
│ │ └── test_routes.py # mirrors inner/api/routes.py
│ └── helpers/
│ └── test_utils.py # mirrors inner/helpers/utils.py
└── my_plugin_name/ # Inner folder (snake_case)
├── CANVAS_MANIFEST.json
├── README.md
├── handlers/
│ ├── vitals_handler.py
│ └── lab_handler.py
├── api/
│ └── routes.py
└── helpers/
└── utils.py
Key points:
tests/ is a sibling to the inner plugin folder, not a childtest_ + source file nameWRONG structure (DO NOT DO THIS):
my-plugin-name/
└── my_plugin_name/
├── handlers/
│ └── handler.py
└── tests/ # WRONG - tests inside inner folder!
└── test_handler.py
If you find tests inside the inner folder, move them:
mv my_plugin_name/tests ./tests
test_ + source file namehandlers/handler.py → tests/handlers/test_handler.pyunittest.mock.MagicMock and patch for all mockingEvery mock MUST have its calls verified. Do not just mock and forget.
# REQUIRED - verify mock was called correctly, with the right arguments, for all calls
with patch("canvas_sdk.v1.data.patient.Patient.objects") as mock_objects:
mock_objects.get.return_value = mock_patient
handler.compute()
calls = [call.get(id="patient-123"), call.get(id="patient-456")]
assert mock_objects.mock_calls == calls # REQUIRED
The pyproject.toml MUST exclude test files from coverage measurement:
[tool.coverage.run]
source = ["plugin_name"]
omit = ["tests/*", "*/tests/*"]
[tool.coverage.report]
omit = ["tests/*", "*/tests/*"]
# Run tests
uv run pytest
# Run tests with coverage
uv run pytest --cov=plugin_name --cov-report=term-missing --cov-branch
# Run tests with HTML coverage report
uv run pytest --cov=plugin_name --cov-report=html
Aim for 90% coverage on plugin code. If coverage is below 90%, offer to write additional tests.
Use manual mocking with MagicMock, NOT factory libraries. Factories don't exist for Canvas plugins. Create test data directly in fixtures and customize per-test. See testing_context.txt for patterns.
Reference the testing_context.txt file in this skill directory for:
Do NOT stop after writing tests. Once tests pass with adequate coverage:
"Tests are passing with X% coverage. The next step is to deploy the plugin to a Canvas instance for user acceptance testing. Ready to deploy?"
/cpa:deploy command to guide deployment and log monitoringAlways drive toward the next step. The workflow is: Implement → Test → Deploy → UAT
Canvas SDK reference and documentation. Use whenever a question, claim, or piece of code touches Canvas SDK capabilities, API usage, implementation patterns, or testing — including quick conversational questions ("how do I ingest ADTs?", "what's the import for X?", "does Canvas support Y?"). The bundled docs are the source of truth; do not answer Canvas SDK questions from memory.
FHIR API reference and documentation for Canvas plugins that need to read or write data via FHIR endpoints
This skill should be used when the user asks to "write tests", "create tests", "generate tests", "unit tests", "pytest", "test guidelines", "testing rules", "test standards", "how to test", "test this code", "add tests", "validate tests", "check tests", "improve tests", or when working with Python test files. Provides comprehensive guidelines for creating pytest unit tests with 100% coverage following strict naming conventions, mock patterns, and parametrization standards.
Custom Data anti-patterns and corrections for Canvas plugins - unnecessary compatibility checks, misuse of AttributeHubs vs CustomModels
Database query optimization for Canvas plugins - N+1 detection, prefetch_related, select_related
Security review for plugins acting as FHIR API clients - token management, scope validation, and patient-scoped authorization