ВяткинАртём
e5dc08987d
- Introduced "Docker Build & Test Engineer" agent for building and testing Docker images. - Added "TestLink Autotest Engineer" agent for generating and verifying autotests from TestLink cases. - Created "Branch Review Engineer" agent for reviewing branch diffs and proposing improvements. - Developed "OpenWrt VPN & Network Engineer" agent for designing and implementing OpenWrt networking with VPN. - Established a structured directory for agents, skills, prompts, instructions, and hooks under `.github/`. - Implemented detailed skills for branch review processes, including reading code, analyzing improvements, and applying changes. - Added skills for OpenWrt network discovery, VPN routing, and hardening. - Created README files for better documentation and navigation of the repository structure.
133 lines
4.5 KiB
Markdown
133 lines
4.5 KiB
Markdown
---
|
|
name: branch-review-check-testlink
|
|
description: "Open a TestLink test case via MCP and verify that the changed autotest in the branch covers all required steps and expected results. Use when: review autotest against TestLink, compare test implementation with TestLink case, verify coverage of written test, проверить автотест по TestLink, сверить тест с тест-кейсом, проверить что автотест покрывает шаги тест-кейса."
|
|
argument-hint: "TestLink test case ID or changed test file/scope"
|
|
---
|
|
|
|
# Branch Review: Check TestLink Coverage
|
|
|
|
This skill verifies that a written autotest actually checks everything required by the authoritative TestLink test case.
|
|
|
|
## When to Use
|
|
|
|
- The branch adds or changes autotests tied to a TestLink case
|
|
- The user explicitly asks to compare a test file with a TestLink case
|
|
- The diff contains a recognizable TestLink reference such as `KMD-123`, `PRJ-42`, or a comment, marker, title, docstring, or test name that maps to a test case
|
|
|
|
## Core Rule
|
|
|
|
Do not assume that a test is complete just because it exists.
|
|
|
|
You must fetch the TestLink case via MCP, read the written autotest, and compare:
|
|
- preconditions
|
|
- scenario steps
|
|
- expected results
|
|
- negative and branching behavior when the TestLink case requires it
|
|
|
|
## Procedure
|
|
|
|
### Step 1 — Resolve the TestLink Case ID
|
|
|
|
Find the most reliable case identifier in this order:
|
|
1. explicit user-provided case ID
|
|
2. exact TestLink ID found in changed test code, comments, docstrings, titles, markers, fixture names, or nearby docs
|
|
3. exact TestLink ID found in commit or branch-related text already provided in context
|
|
|
|
Accepted formats:
|
|
- numeric internal ID, for example `1831`
|
|
- external ID, for example `KMD-1831`
|
|
|
|
If there is no reliable ID, stop this skill and report:
|
|
- no TestLink case could be resolved from the branch
|
|
- what evidence was checked
|
|
|
|
### Step 2 — Fetch the Authoritative Test Case
|
|
|
|
Call TestLink MCP to load the case.
|
|
|
|
Use:
|
|
- `external_id` for prefixed identifiers such as `KMD-1831`
|
|
- `test_case_id` for plain numeric identifiers
|
|
|
|
Extract at minimum:
|
|
- `id` and `external_id`
|
|
- `name`
|
|
- `summary`
|
|
- `preconditions`
|
|
- `steps[].step_number`
|
|
- `steps[].actions`
|
|
- `steps[].expected_results`
|
|
|
|
If the case is not found, report it and stop this skill.
|
|
|
|
### Step 3 — Read the Written Test Thoroughly
|
|
|
|
Read the changed test file and any directly related helpers or fixtures that are necessary to understand what is actually asserted.
|
|
|
|
Determine:
|
|
- what setup the test performs
|
|
- what actions it executes
|
|
- what it asserts explicitly
|
|
- what it only implies but does not verify
|
|
- what parts of the TestLink case are not covered at all
|
|
|
|
Be strict here:
|
|
- execution of a step is not the same as verification of a result
|
|
- logging or comments are not assertions
|
|
- helper names do not count as coverage unless the underlying assertion is visible or can be traced with confidence
|
|
|
|
### Step 4 — Build a Coverage Matrix
|
|
|
|
Map the TestLink case to the written test.
|
|
|
|
For every TestLink step, classify coverage as one of:
|
|
- `Covered` — the test clearly performs the step and verifies the expected result
|
|
- `Partial` — the test performs the step but misses all or part of the required verification
|
|
- `Missing` — the step or expected result is not covered
|
|
- `Unclear` — likely covered indirectly, but the assertion path cannot be confirmed from the code
|
|
|
|
Also assess preconditions:
|
|
- fully represented
|
|
- partially represented
|
|
- missing
|
|
|
|
### Step 5 — Produce Review Findings
|
|
|
|
Output findings focused on concrete gaps.
|
|
|
|
Template:
|
|
|
|
```md
|
|
## TestLink Coverage Check
|
|
|
|
Case: <external_id or id> — <title>
|
|
Source test: <file or symbol>
|
|
|
|
### Coverage Summary
|
|
- Preconditions: covered/partial/missing
|
|
- Steps covered: X/Y
|
|
- Partial: N
|
|
- Missing: N
|
|
- Unclear: N
|
|
|
|
### Coverage Matrix
|
|
1. Step <N>: <short action>
|
|
- expected: <short expected result>
|
|
- status: Covered | Partial | Missing | Unclear
|
|
- evidence: <test function / assertion / helper>
|
|
|
|
### Gaps
|
|
1. <gap title>
|
|
- why it matters: ...
|
|
- recommended fix: ...
|
|
- safe to auto-apply: yes/no
|
|
```
|
|
|
|
## Review Guidance
|
|
|
|
- Treat `Missing` and `Partial` coverage as review findings
|
|
- Escalate to `Critical` when a missing check can hide a regression in the core scenario
|
|
- Escalate to `Important` when the flow exists but the expected result is not asserted
|
|
- Put naming-only or traceability-only improvements into `Optional` unless they block reliable mapping to TestLink
|
|
|
|
Do not edit files in this skill. It only produces coverage analysis for the proposal stage. |