akanealw/Charon
1
0
Fork 0
Code Issues Pull Requests Actions 16 Packages Projects Releases Wiki Activity

feat: update testing instructions to enhance clarity and detail on execution protocols

Browse Source
This commit is contained in:
GitHub Actions
2025-12-19 05:00:35 +00:00
parent 097d44b874
commit 03518145c0
1 changed files with 12 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
.github/instructions/testing.instructions.md vendored
View File

@@ -1,13 +1,18 @@
---
applyTo: '**'
description: 'Testing instructions for code and content validation.'
description: 'Strict protocols for test execution, debugging, and coverage validation.'
---
# Testing Instructions
# Testing Protocols
1. Never run tests using tail or head flags that limit the output. Some tests require user interaction and hang if output is truncated. Always run tests in a way that allows full output to be visible.
## 1. Execution Environment
* **No Truncation:** Never use pipe commands (e.g., `head`, `tail`) or flags that limit stdout/stderr. If a test hangs, it likely requires an interactive input or is caught in a loop; analyze the full output to identify the block.
* **Task-Based Execution:** Do not manually construct test strings. Use existing project tasks (e.g., `npm test`, `go test ./...`). If a specific sub-module requires frequent testing, generate a new task definition in the project's configuration file (e.g., `.vscode/tasks.json`) before proceeding.
2. When running tests, don't holucinate paths or filenames. Always use prebuilt tasks. If there is not a task for repetitive testing, create one that fits the project's conventions.
## 2. Failure Analysis & Logic Integrity
* **Evidence-Based Debugging:** When a test fails, you must quote the specific error message or stack trace before suggesting a fix.
* **Bug vs. Test Flaw:** Treat the test as the "Source of Truth." If a test fails, assume the code is broken until proven otherwise. Research the original requirement or PR description to verify if the test logic itself is outdated before modifying it.
* **Zero-Hallucination Policy:** Only use file paths and identifiers discovered via the `ls` or `search` tools. Never guess a path based on naming conventions.
3. When tests fail, always analyze the output carefully. Look for stack traces, error messages, and any hints that indicate what went wrong. Avoid making assumptions without evidence from the test results. Don't fix the test to run based on the code as it may be failing because there is a bug in the code. Always research to make sure if its the code that needs fixed or the test.
4. It is fine to run just the tests when creating and troubleshooting but the last step before completion is to run the tests with coverage to make sure we stay above the coverage threshold.
## 3. Coverage & Completion
* **Coverage Gate:** A task is not "Complete" until a coverage report is generated.
* **Threshold Compliance:** You must compare the final coverage percentage against the project's threshold (Default: 85% unless specified otherwise). If coverage drops, you must identify the "uncovered lines" and add targeted tests.