netalertx PR Analysis
Before Writing Any Test Code — Non-Negotiable Checklist
Run through this before creating or editing any file under test/:
- Helpers first: Check
test/db_test_helpers.pyfor existing factories (make_db,make_device_dict,insert_device_from_dict,DummyDB). Use them. If what you need doesn't exist, add it there — never define it locally in the test file. - MAC literals must be lowercase: Every MAC string in fixtures,
parametrize, assertions, docstrings, and comments must be lowercase hex (e.g.aa:bb:cc:dd:ee:01). No exceptions. - Test file location: Place new tests under a subdirectory of
test/that mirrors the source path (e.g.test/scan/forserver/scan/). Don't add new files directly intest/root - a handful of existing ones there (e.g.test_plugin_helper.py,test_wol_validation.py) predate this convention; that's not license to add more, but don't migrate them unprompted either. - No inline imports: All imports at the top of the file.
Before Acting on Any PR Comment
- Load
code-standardsskill — all code changes must comply with it before replying. - Load
testing-workflowskill — any test additions or changes must follow it. - Load any domain-specific skill relevant to the files being changed (e.g.
database-patternsfor DB writes,settings-managementfor config).
Comment Classification
For each comment, determine:
| Type | Action |
|---|---|
| Request for code change | Make the change, validate it, then reply with the short commit hash |
| Question about code | Reply with a concise answer (no restatement of the question) |
| Suggestion / feedback | Decide if it is actionable. If yes, act and reply. If not, do not reply. |
| General / praise | Do not reply. |
Acting on Comments — Step by Step
- Identify all actionable comments before touching any file.
- Load relevant skills to understand conventions that apply.
- Prepare a plan — list each file and the exact change required.
- Make changes one comment at a time — keep commits focused.
- Run targeted tests after each change (
testing-workflowskill). - Reply only after the commit is pushed via
report_progress. Include the short SHA.
Reply Guidelines
- Be concise. Do not summarize or restate the original comment.
- State what was done and (optionally) why.
- Include the short commit hash when relevant.
- Do not thank or compliment the reviewer.
What to Check After Every Batch of Changes
- MAC literals lowercase — grep for uppercase hex in every changed test file:
grep -Pn '[0-9A-F]{2}:[0-9A-F]' test/must be empty. - No local DB helpers — no
DummyDB,make_db, or inline DDL defined outsidetest/db_test_helpers.py. - No inline imports — all imports at the top of the file.
- Tests live under a subdirectory of
test/matching the source path, not intest/root. - Secret scan (
runtime-tools-secret_scanning) before committing.
Stacked / Base-Branch Issues
When a PR targets a non-default branch (e.g. next_release):
- Do not retarget the branch yourself; note it in a reply so the author can do it from the GitHub UI.
- Check CI failures on the base branch first before checking your branch.