@pzy560117/opentest 0.1.3 → 0.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +57 -8
- package/assets/manifest.json +84 -27
- package/assets/skills/opentest/SKILL.md +44 -44
- package/assets/skills/opentest/references/codex-harness-coverage-heuristics.md +55 -55
- package/assets/skills/opentest/references/lifecycle.md +1 -1
- package/assets/skills/opentest/references/matrix-format.md +14 -14
- package/assets/skills/opentest/references/opentest-driven-development.md +32 -32
- package/assets/skills/opentest/templates/acceptance-template.md +1 -1
- package/assets/skills/opentest/templates/matrix-template.md +3 -3
- package/assets/skills/opentest/templates/plan-template.md +17 -17
- package/assets/skills/opentest/templates/report-template.md +1 -1
- package/assets/skills/opentest-accept/SKILL.md +13 -13
- package/assets/skills/opentest-archive/SKILL.md +2 -2
- package/assets/skills/opentest-author/SKILL.md +14 -14
- package/assets/skills/opentest-heal/SKILL.md +2 -2
- package/assets/skills/opentest-plan/SKILL.md +17 -17
- package/assets/skills/opentest-run/SKILL.md +16 -16
- package/assets/skills/opentest-verify/SKILL.md +11 -11
- package/assets/skills-zh/opentest/SKILL.md +93 -0
- package/assets/skills-zh/opentest/references/acceptance-evidence.md +27 -0
- package/assets/skills-zh/opentest/references/codex-harness-coverage-heuristics.md +83 -0
- package/assets/skills-zh/opentest/references/command-routing.md +9 -0
- package/assets/skills-zh/opentest/references/lifecycle.md +16 -0
- package/assets/skills-zh/opentest/references/matrix-format.md +27 -0
- package/assets/skills-zh/opentest/references/opentest-driven-development.md +48 -0
- package/assets/skills-zh/opentest/references/quality-gate.md +24 -0
- package/assets/skills-zh/opentest/templates/acceptance-template.md +32 -0
- package/assets/skills-zh/opentest/templates/archive-layout.md +14 -0
- package/assets/skills-zh/opentest/templates/matrix-template.md +6 -0
- package/assets/skills-zh/opentest/templates/plan-template.md +28 -0
- package/assets/skills-zh/opentest/templates/report-template.md +28 -0
- package/assets/skills-zh/opentest-accept/SKILL.md +25 -0
- package/assets/skills-zh/opentest-archive/SKILL.md +8 -0
- package/assets/skills-zh/opentest-author/SKILL.md +27 -0
- package/assets/skills-zh/opentest-heal/SKILL.md +8 -0
- package/assets/skills-zh/opentest-plan/SKILL.md +30 -0
- package/assets/skills-zh/opentest-run/SKILL.md +28 -0
- package/assets/skills-zh/opentest-verify/SKILL.md +24 -0
- package/bin/opentest.js +318 -29
- package/package.json +1 -1
- package/scripts/prepublish-check.js +105 -6
- package/scripts/smoke-test.js +493 -23
package/README.md
CHANGED
|
@@ -26,25 +26,73 @@ requirement / design
|
|
|
26
26
|
|
|
27
27
|
## Install
|
|
28
28
|
|
|
29
|
-
Install
|
|
29
|
+
Install the package, then run the initializer from any project:
|
|
30
30
|
|
|
31
31
|
```bash
|
|
32
|
-
|
|
32
|
+
npm install -g @pzy560117/opentest
|
|
33
|
+
opentest init
|
|
33
34
|
```
|
|
34
35
|
|
|
35
|
-
|
|
36
|
+
`opentest init` lets you choose the target tool, language, project/global scope, and project path. This is the recommended path for Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Qwen Code, and Qoder users.
|
|
37
|
+
|
|
38
|
+
You can still run fully scripted installs. For example, install Chinese OpenTest skills for Claude Code in the current project:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
opentest install --scope project --platform claude --language zh
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Install Chinese OpenTest skills for Qoder in a specific project:
|
|
36
45
|
|
|
37
46
|
```bash
|
|
38
|
-
npx @pzy560117/opentest install --
|
|
47
|
+
npx @pzy560117/opentest install --scope project --platform qoder --language zh --project /path/to/project
|
|
39
48
|
```
|
|
40
49
|
|
|
41
|
-
|
|
50
|
+
Install Chinese OpenTest skills globally for Codex:
|
|
42
51
|
|
|
43
52
|
```bash
|
|
44
|
-
npx @pzy560117/opentest install --
|
|
53
|
+
npx @pzy560117/opentest install --scope global --platform codex --language zh
|
|
45
54
|
```
|
|
46
55
|
|
|
47
|
-
|
|
56
|
+
Legacy global install with overwrite:
|
|
57
|
+
|
|
58
|
+
```bash
|
|
59
|
+
npx @pzy560117/opentest install --global --force
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
Legacy project install with overwrite:
|
|
63
|
+
|
|
64
|
+
```bash
|
|
65
|
+
npx @pzy560117/opentest install --project /path/to/project --force
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
### Install Options
|
|
69
|
+
|
|
70
|
+
| Option | Meaning | Default |
|
|
71
|
+
| --- | --- | --- |
|
|
72
|
+
| `--scope <project|global>` | Install into the selected project skills directory or the user's global skills directory. | `project` |
|
|
73
|
+
| `--platform <id>` | Target AI programming tool. Supported IDs are listed below and are read by the CLI from `assets/manifest.json`. | `codex` |
|
|
74
|
+
| `--language <en|zh>` | Skill language to install. `en` installs English skills; `zh` installs Chinese skills. | `en` |
|
|
75
|
+
| `--project <path>` | Project root used for project-scope installs. This also selects project scope for legacy compatibility. | Current working directory |
|
|
76
|
+
| `--global` | Legacy alias for `--scope global --platform codex`. | Disabled |
|
|
77
|
+
| `--force` | Overwrite existing manifest-managed OpenTest skill directories. | Disabled |
|
|
78
|
+
|
|
79
|
+
### Supported Platforms
|
|
80
|
+
|
|
81
|
+
The CLI reads platform data directly from the package manifest at `assets/manifest.json`; the paths below are shown using project-relative and home-relative notation.
|
|
82
|
+
|
|
83
|
+
| Platform ID | Tool | Project skills directory | Global skills directory |
|
|
84
|
+
| --- | --- | --- | --- |
|
|
85
|
+
| `codex` | Codex | `.codex/skills` | `~/.codex/skills` |
|
|
86
|
+
| `claude` | Claude Code | `.claude/skills` | `~/.claude/skills` |
|
|
87
|
+
| `cursor` | Cursor | `.cursor/skills` | `~/.cursor/skills` |
|
|
88
|
+
| `opencode` | OpenCode | `.opencode/skills` | `~/.config/opencode/skills` |
|
|
89
|
+
| `gemini` | Gemini CLI | `.gemini/skills` | `~/.gemini/skills` |
|
|
90
|
+
| `qwen` | Qwen Code | `.qwen/skills` | `~/.qwen/skills` |
|
|
91
|
+
| `qoder` | Qoder | `.qoder/skills` | `~/.qoder/skills` |
|
|
92
|
+
|
|
93
|
+
When adding a platform, update at least `assets/manifest.json` and `scripts/smoke-test.js` in this package so the installer data and smoke coverage stay in sync. Update this README table in the same change.
|
|
94
|
+
|
|
95
|
+
Restart the target AI programming tool or open a new session after installation so the new skills are loaded.
|
|
48
96
|
|
|
49
97
|
## Included Skills
|
|
50
98
|
|
|
@@ -59,6 +107,7 @@ Restart Codex or open a new session after installation so the new skills are loa
|
|
|
59
107
|
|
|
60
108
|
## Package Contents
|
|
61
109
|
|
|
62
|
-
- `assets/skills/`:
|
|
110
|
+
- `assets/skills/`: English skill files
|
|
111
|
+
- `assets/skills-zh/`: Chinese skill files
|
|
63
112
|
- `assets/manifest.json`: published asset manifest
|
|
64
113
|
- `bin/opentest.js`: installer CLI
|
package/assets/manifest.json
CHANGED
|
@@ -1,31 +1,88 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "0.1.
|
|
3
|
-
"
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
"opentest/references/opentest-driven-development.md",
|
|
15
|
-
"opentest/templates/plan-template.md",
|
|
16
|
-
"opentest/templates/matrix-template.md",
|
|
17
|
-
"opentest/templates/acceptance-template.md",
|
|
18
|
-
"opentest/templates/report-template.md",
|
|
19
|
-
"opentest/templates/archive-layout.md",
|
|
20
|
-
"opentest-plan/SKILL.md",
|
|
21
|
-
"opentest-author/SKILL.md",
|
|
22
|
-
"opentest-run/SKILL.md",
|
|
23
|
-
"opentest-accept/SKILL.md",
|
|
24
|
-
"opentest-verify/SKILL.md",
|
|
25
|
-
"opentest-heal/SKILL.md",
|
|
26
|
-
"opentest-archive/SKILL.md"
|
|
2
|
+
"version": "0.1.5",
|
|
3
|
+
"languages": [
|
|
4
|
+
{
|
|
5
|
+
"id": "en",
|
|
6
|
+
"name": "English",
|
|
7
|
+
"skillsDir": "skills"
|
|
8
|
+
},
|
|
9
|
+
{
|
|
10
|
+
"id": "zh",
|
|
11
|
+
"name": "中文",
|
|
12
|
+
"skillsDir": "skills-zh"
|
|
13
|
+
}
|
|
27
14
|
],
|
|
28
15
|
"platforms": [
|
|
29
|
-
{
|
|
30
|
-
|
|
16
|
+
{
|
|
17
|
+
"id": "codex",
|
|
18
|
+
"name": "Codex",
|
|
19
|
+
"projectSkillsDir": ".codex/skills",
|
|
20
|
+
"globalSkillsDir": "~/.codex/skills"
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"id": "claude",
|
|
24
|
+
"name": "Claude Code",
|
|
25
|
+
"projectSkillsDir": ".claude/skills",
|
|
26
|
+
"globalSkillsDir": "~/.claude/skills"
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "cursor",
|
|
30
|
+
"name": "Cursor",
|
|
31
|
+
"projectSkillsDir": ".cursor/skills",
|
|
32
|
+
"globalSkillsDir": "~/.cursor/skills"
|
|
33
|
+
},
|
|
34
|
+
{
|
|
35
|
+
"id": "opencode",
|
|
36
|
+
"name": "OpenCode",
|
|
37
|
+
"projectSkillsDir": ".opencode/skills",
|
|
38
|
+
"globalSkillsDir": ".config/opencode/skills"
|
|
39
|
+
},
|
|
40
|
+
{
|
|
41
|
+
"id": "gemini",
|
|
42
|
+
"name": "Gemini CLI",
|
|
43
|
+
"projectSkillsDir": ".gemini/skills",
|
|
44
|
+
"globalSkillsDir": "~/.gemini/skills"
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "qwen",
|
|
48
|
+
"name": "Qwen Code",
|
|
49
|
+
"projectSkillsDir": ".qwen/skills",
|
|
50
|
+
"globalSkillsDir": "~/.qwen/skills"
|
|
51
|
+
},
|
|
52
|
+
{
|
|
53
|
+
"id": "qoder",
|
|
54
|
+
"name": "Qoder",
|
|
55
|
+
"projectSkillsDir": ".qoder/skills",
|
|
56
|
+
"globalSkillsDir": "~/.qoder/skills"
|
|
57
|
+
}
|
|
58
|
+
],
|
|
59
|
+
"managedFiles": {
|
|
60
|
+
"localized": [
|
|
61
|
+
"opentest/SKILL.md",
|
|
62
|
+
"opentest/references/acceptance-evidence.md",
|
|
63
|
+
"opentest/references/codex-harness-coverage-heuristics.md",
|
|
64
|
+
"opentest/references/command-routing.md",
|
|
65
|
+
"opentest/references/lifecycle.md",
|
|
66
|
+
"opentest/references/matrix-format.md",
|
|
67
|
+
"opentest/references/opentest-driven-development.md",
|
|
68
|
+
"opentest/references/quality-gate.md",
|
|
69
|
+
"opentest/templates/acceptance-template.md",
|
|
70
|
+
"opentest/templates/archive-layout.md",
|
|
71
|
+
"opentest/templates/matrix-template.md",
|
|
72
|
+
"opentest/templates/plan-template.md",
|
|
73
|
+
"opentest/templates/report-template.md",
|
|
74
|
+
"opentest-accept/SKILL.md",
|
|
75
|
+
"opentest-archive/SKILL.md",
|
|
76
|
+
"opentest-author/SKILL.md",
|
|
77
|
+
"opentest-heal/SKILL.md",
|
|
78
|
+
"opentest-plan/SKILL.md",
|
|
79
|
+
"opentest-run/SKILL.md",
|
|
80
|
+
"opentest-verify/SKILL.md"
|
|
81
|
+
],
|
|
82
|
+
"shared": [
|
|
83
|
+
"opentest/scripts/opentest-state.sh",
|
|
84
|
+
"opentest/scripts/opentest-detect.sh",
|
|
85
|
+
"opentest/scripts/opentest-guard.sh"
|
|
86
|
+
]
|
|
87
|
+
}
|
|
31
88
|
}
|
|
@@ -1,93 +1,93 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: opentest
|
|
3
|
-
description: "OpenTest
|
|
3
|
+
description: "OpenTest router. Detects .opentest.yaml, initializes test lifecycle state, and dispatches to plan/author/run/accept/verify/heal/archive phases."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# OpenTest
|
|
6
|
+
# OpenTest Router
|
|
7
7
|
|
|
8
|
-
OpenTest
|
|
8
|
+
OpenTest is a test decision and quality evidence lifecycle for AI coding changes. It is not just a TDD wrapper, and it is not just a command runner at the end of implementation. Before implementation, it turns explicit requirements, implicit boundaries, failure paths, interaction feedback, and risk scenarios into a test matrix, then uses that matrix to drive code, acceptance, and quality gates.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Output Language Contract
|
|
11
11
|
|
|
12
|
-
-
|
|
13
|
-
-
|
|
12
|
+
- User-facing output and generated documents default to English.
|
|
13
|
+
- Commands, paths, frontmatter keys, code identifiers, and API names stay as written.
|
|
14
14
|
|
|
15
|
-
## Step 0:
|
|
15
|
+
## Step 0: Locate Scripts
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
Run:
|
|
18
18
|
|
|
19
19
|
```bash
|
|
20
|
-
OPENTEST_SEARCH_ROOTS=("." "$HOME/.
|
|
20
|
+
OPENTEST_SEARCH_ROOTS=("." ".codex/skills" ".claude/skills" ".cursor/skills" ".opencode/skills" ".gemini/skills" ".qwen/skills" ".qoder/skills" "$HOME/.codex/skills" "$HOME/.claude/skills" "$HOME/.cursor/skills" "$HOME/.config/opencode/skills" "$HOME/.gemini/skills" "$HOME/.qwen/skills" "$HOME/.qoder/skills")
|
|
21
21
|
OPENTEST_STATE="${OPENTEST_STATE:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-state.sh' -type f -print -quit 2>/dev/null)}"
|
|
22
22
|
OPENTEST_GUARD="${OPENTEST_GUARD:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-guard.sh' -type f -print -quit 2>/dev/null)}"
|
|
23
23
|
OPENTEST_DETECT="${OPENTEST_DETECT:-$(find "${OPENTEST_SEARCH_ROOTS[@]}" -path '*/opentest/scripts/opentest-detect.sh' -type f -print -quit 2>/dev/null)}"
|
|
24
24
|
```
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
If any script is missing, stop and ask the user to install or copy the OpenTest distribution.
|
|
27
27
|
|
|
28
|
-
## Step 1:
|
|
28
|
+
## Step 1: Detect State
|
|
29
29
|
|
|
30
|
-
|
|
30
|
+
If `docs/loop-handoff/latest.md` exists, read it first to recover the previous OpenTest phase, matrix/acceptance/report paths, blockers, and next step. The handoff is only a recovery hint; it does not replace `.opentest.yaml`.
|
|
31
31
|
|
|
32
|
-
|
|
32
|
+
If `.opentest.yaml` does not exist, run:
|
|
33
33
|
|
|
34
34
|
```bash
|
|
35
35
|
bash "$OPENTEST_STATE" init
|
|
36
36
|
```
|
|
37
37
|
|
|
38
|
-
|
|
38
|
+
Then run:
|
|
39
39
|
|
|
40
40
|
```bash
|
|
41
41
|
bash "$OPENTEST_STATE" check
|
|
42
42
|
bash "$OPENTEST_DETECT" summary
|
|
43
43
|
```
|
|
44
44
|
|
|
45
|
-
## Step 2:
|
|
45
|
+
## Step 2: Dispatch Phase
|
|
46
46
|
|
|
47
|
-
|
|
47
|
+
Read `phase`:
|
|
48
48
|
|
|
49
49
|
```bash
|
|
50
50
|
bash "$OPENTEST_STATE" get phase
|
|
51
51
|
```
|
|
52
52
|
|
|
53
|
-
|
|
53
|
+
Dispatch rules:
|
|
54
54
|
|
|
55
|
-
- `archived: true
|
|
56
|
-
- `phase: plan
|
|
57
|
-
- `phase: author
|
|
58
|
-
- `phase: run
|
|
59
|
-
- `phase: accept
|
|
60
|
-
- `phase: verify
|
|
61
|
-
- `phase: heal
|
|
62
|
-
- `phase: archive
|
|
55
|
+
- `archived: true`: report that OpenTest is complete.
|
|
56
|
+
- `phase: plan`: invoke `opentest-plan`.
|
|
57
|
+
- `phase: author`: invoke `opentest-author`.
|
|
58
|
+
- `phase: run`: invoke `opentest-run`.
|
|
59
|
+
- `phase: accept`: invoke `opentest-accept`.
|
|
60
|
+
- `phase: verify`: invoke `opentest-verify`.
|
|
61
|
+
- `phase: heal`: invoke `opentest-heal`.
|
|
62
|
+
- `phase: archive`: invoke `opentest-archive`.
|
|
63
63
|
|
|
64
|
-
|
|
64
|
+
If state conflicts with verifiable files, trust the files and repair state with `opentest-state.sh set`. If a handoff exists, also update its current phase, next step, failures, and blockers.
|
|
65
65
|
|
|
66
|
-
## OpenTest-Driven Development
|
|
66
|
+
## OpenTest-Driven Development Usage
|
|
67
67
|
|
|
68
|
-
|
|
68
|
+
When the user wants test-driven development, or when the requirement includes frontend interactions, login, forms, permissions, APIs, data writes, cross-page flows, or high-risk behavior, OpenTest must run before build work:
|
|
69
69
|
|
|
70
70
|
```text
|
|
71
|
-
|
|
72
|
-
-> opentest plan #
|
|
73
|
-
-> opentest author #
|
|
74
|
-
-> build #
|
|
75
|
-
-> opentest run # unit / integration / smoke / e2e
|
|
76
|
-
-> opentest accept #
|
|
77
|
-
-> opentest verify #
|
|
71
|
+
Requirement / OpenSuper design
|
|
72
|
+
-> opentest plan # implicit scenario mining + acceptance-to-test matrix
|
|
73
|
+
-> opentest author # test assets / natural language acceptance cases
|
|
74
|
+
-> build # implement against the matrix
|
|
75
|
+
-> opentest run # unit / integration / smoke / e2e commands
|
|
76
|
+
-> opentest accept # real page, API, or workflow acceptance
|
|
77
|
+
-> opentest verify # quality gate report
|
|
78
78
|
```
|
|
79
79
|
|
|
80
|
-
`plan`
|
|
80
|
+
The `plan` phase must not merely restate requirements. It must actively inspect:
|
|
81
81
|
|
|
82
|
-
-
|
|
83
|
-
-
|
|
84
|
-
-
|
|
85
|
-
-
|
|
82
|
+
- Happy paths, failure paths, boundary inputs, empty data, permissions, network failures, duplicate submissions, concurrency, and stale state.
|
|
83
|
+
- Frontend feedback location: field-level message, form-level alert, toast, modal, inline status, or page error state.
|
|
84
|
+
- Evidence layers: unit, component, integration, contract, E2E, smoke, visual/browser acceptance, and security/review.
|
|
85
|
+
- Which evidence is required, which is not applicable, and which is a gap or risk-accepted candidate.
|
|
86
86
|
|
|
87
|
-
|
|
87
|
+
After implementation, `OpenSuper verify` may reference the OpenTest verification report, but it does not replace the OpenTest matrix, run records, or acceptance evidence.
|
|
88
88
|
|
|
89
|
-
## Loop Handoff
|
|
89
|
+
## Loop Handoff Integration
|
|
90
90
|
|
|
91
|
-
OpenTest
|
|
91
|
+
After OpenTest completes any `plan`, `author`, `run`, `accept`, or `verify` phase, update `docs/loop-handoff/latest.md` when the project uses Loop Handoff. At minimum, record the `.opentest.yaml` path, current phase, test asset paths, verification already run, verification not run, failures/blockers, and next step.
|
|
92
92
|
|
|
93
|
-
`opentest-verify`
|
|
93
|
+
The verification report path produced by `opentest-verify` must be written to the handoff so OpenSuper verify or a resumed session can reference it directly.
|
|
@@ -1,14 +1,14 @@
|
|
|
1
|
-
# Codex Harness
|
|
1
|
+
# Codex Harness Coverage Heuristics
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## Purpose
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
This file ships with OpenTest to provide lightweight coverage heuristics for `/opentest-plan` and `/opentest-accept`. It is not a mandatory checklist and is not a full copy of Codex Harness content.
|
|
6
6
|
|
|
7
|
-
OpenTest
|
|
7
|
+
OpenTest should select applicable coverage from the change type, risk, and project facts. Applicable coverage without evidence should be recorded as `gap`. Non-applicable coverage should be briefly explained in the coverage summary and does not need expanded cases.
|
|
8
8
|
|
|
9
|
-
##
|
|
9
|
+
## Sources
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
This reference extracts short rules from the local Codex Harness knowledge base, primarily corresponding to:
|
|
12
12
|
|
|
13
13
|
- `tdd-workflow`
|
|
14
14
|
- `e2e-runner`
|
|
@@ -17,67 +17,67 @@ OpenTest 应根据变更类型、风险和项目事实选择适用覆盖面。
|
|
|
17
17
|
- `code-reviewer`
|
|
18
18
|
- `speckit-checklist`
|
|
19
19
|
|
|
20
|
-
##
|
|
20
|
+
## Selection Rules
|
|
21
21
|
|
|
22
|
-
|
|
|
22
|
+
| Change type | Default evidence to consider |
|
|
23
23
|
| --- | --- |
|
|
24
|
-
|
|
|
25
|
-
|
|
|
26
|
-
|
|
|
27
|
-
|
|
|
28
|
-
|
|
|
29
|
-
|
|
|
24
|
+
| Pure functions, utility functions, state calculation | unit evidence |
|
|
25
|
+
| Services, module collaboration, database reads/writes | integration evidence |
|
|
26
|
+
| APIs, contracts, error handling | contract, integration, error evidence |
|
|
27
|
+
| Frontend rendering or interaction | UI acceptance, plus component or E2E evidence when needed |
|
|
28
|
+
| Permissions, payments, security, data writes, cross-page loops | high-risk acceptance or E2E evidence |
|
|
29
|
+
| Copy, configuration, small non-behavioral changes | targeted review or light evidence |
|
|
30
30
|
|
|
31
|
-
##
|
|
31
|
+
## Frontend Acceptance Dimensions
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
Frontend or real workflow acceptance may choose applicable items from the following dimensions. Full coverage is not required every time:
|
|
34
34
|
|
|
35
|
-
|
|
|
35
|
+
| Dimension | Meaning |
|
|
36
36
|
| --- | --- |
|
|
37
|
-
| D1
|
|
38
|
-
| D2
|
|
39
|
-
| D3
|
|
40
|
-
| D4
|
|
41
|
-
| D5
|
|
42
|
-
| D6
|
|
43
|
-
| D7
|
|
44
|
-
| D8 UI
|
|
45
|
-
| D9
|
|
46
|
-
| D10
|
|
47
|
-
|
|
48
|
-
##
|
|
49
|
-
|
|
50
|
-
OpenTest plan
|
|
51
|
-
|
|
52
|
-
|
|
|
37
|
+
| D1 Page rendering | Title, copy, structure, primary elements exist |
|
|
38
|
+
| D2 Interaction behavior | Click, input, selection, dialog, menu |
|
|
39
|
+
| D3 Data display | API data, formatting, status display |
|
|
40
|
+
| D4 Form validation | Required fields, format, boundary, dependent validation |
|
|
41
|
+
| D5 Navigation flow | Menu, link, back path, cross-page parameter passing |
|
|
42
|
+
| D6 State management | loading, empty, error, retry |
|
|
43
|
+
| D7 Permission control | Roles, route guards, unauthorized access blocking |
|
|
44
|
+
| D8 UI feedback | toast, modal, loading indicator |
|
|
45
|
+
| D9 Component coordination | Filters, tabs, counts, cascading changes |
|
|
46
|
+
| D10 Boundary cases | Empty data, long text, special input, missing prerequisite data |
|
|
47
|
+
|
|
48
|
+
## Default Implicit Scenario Mining
|
|
49
|
+
|
|
50
|
+
The OpenTest plan phase checks these questions by default. If applicable, add them to the matrix; if not applicable, explain briefly:
|
|
51
|
+
|
|
52
|
+
| Category | Default question |
|
|
53
53
|
| --- | --- |
|
|
54
|
-
|
|
|
55
|
-
|
|
|
56
|
-
|
|
|
57
|
-
|
|
|
58
|
-
|
|
|
59
|
-
|
|
|
60
|
-
|
|
|
61
|
-
|
|
|
62
|
-
|
|
|
63
|
-
|
|
|
64
|
-
|
|
|
65
|
-
|
|
|
66
|
-
|
|
67
|
-
##
|
|
68
|
-
|
|
69
|
-
`/opentest-plan`
|
|
54
|
+
| Empty input | Does an empty field block submit, and does the error appear below the field or at form level? |
|
|
55
|
+
| Invalid input | How are format, length, range, duplicate values, and dependent fields reported? |
|
|
56
|
+
| Network failure | Is a network error and retry entry shown, and is user input preserved? |
|
|
57
|
+
| Server failure | Are 4xx/5xx failures distinguished, and are technical details avoided? |
|
|
58
|
+
| Auth/session | How are expired tokens, unauthenticated access, and signed-in visits to login handled? |
|
|
59
|
+
| Missing permissions | Is the action hidden, disabled, or explained with permission copy? |
|
|
60
|
+
| Duplicate submit | Does the submitting button state prevent duplicate requests, and is idempotency or conflict handled? |
|
|
61
|
+
| Empty data | Are initial empty state and filtered no-result state distinguished? |
|
|
62
|
+
| Long content/large data | Are pagination, truncation, virtualization, long text, and extreme counts handled? |
|
|
63
|
+
| Mobile | Are keyboard overlap, touch targets, narrow layout, and return paths handled? |
|
|
64
|
+
| Accessibility | Are keyboard path, focus, error association, and screen reader hints handled? |
|
|
65
|
+
| Security | Are sensitive information, authorization bypass, injection, CSRF, and duplicate action risks considered? |
|
|
66
|
+
|
|
67
|
+
## Output Constraints
|
|
68
|
+
|
|
69
|
+
`/opentest-plan` should prefer a narrow matrix:
|
|
70
70
|
|
|
71
71
|
```markdown
|
|
72
|
-
| ID |
|
|
72
|
+
| ID | Intent | Risk | Required evidence | Status |
|
|
73
73
|
| --- | --- | --- | --- | --- |
|
|
74
|
-
| ACC-001 |
|
|
74
|
+
| ACC-001 | User sees success feedback after save | medium | UI acceptance | pending |
|
|
75
75
|
```
|
|
76
76
|
|
|
77
|
-
|
|
77
|
+
Add coverage dimension, command, evidence path, and blocker reason columns only when risk or change type requires them.
|
|
78
78
|
|
|
79
|
-
##
|
|
79
|
+
## Quality Gate Heuristics
|
|
80
80
|
|
|
81
|
-
|
|
81
|
+
Verification is recommended in build, type, lint, test, security, diff order. Build, type, lint, required test, or required acceptance failures should block pass. Non-required evidence gaps may be recorded as explainable risk.
|
|
82
82
|
|
|
83
|
-
|
|
83
|
+
When tooling, environment, prerequisite data, or MCP is unavailable, record `blocked` evidence and do not claim acceptance passed.
|
|
@@ -2,26 +2,26 @@
|
|
|
2
2
|
|
|
3
3
|
## Minimal Columns
|
|
4
4
|
|
|
5
|
-
| ID |
|
|
5
|
+
| ID | Intent | Trigger/Input | Expected behavior | Risk | Evidence layer | Required evidence | Status |
|
|
6
6
|
| --- | --- | --- | --- | --- | --- | --- | --- |
|
|
7
7
|
|
|
8
8
|
## Optional Columns
|
|
9
9
|
|
|
10
|
-
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
10
|
+
- Coverage
|
|
11
|
+
- Command
|
|
12
|
+
- Evidence path
|
|
13
|
+
- Blocker reason
|
|
14
|
+
- Risk acceptance note
|
|
15
15
|
|
|
16
16
|
Only add optional columns when risk or change type needs them.
|
|
17
17
|
|
|
18
18
|
## Evidence Layers
|
|
19
19
|
|
|
20
|
-
- `unit
|
|
21
|
-
- `component
|
|
22
|
-
- `integration
|
|
23
|
-
- `contract
|
|
24
|
-
- `e2e
|
|
25
|
-
- `smoke
|
|
26
|
-
- `browser-acceptance
|
|
27
|
-
- `security-review
|
|
20
|
+
- `unit`: pure functions, validation rules, state calculation.
|
|
21
|
+
- `component`: form feedback, button states, local UI states.
|
|
22
|
+
- `integration`: module collaboration, API client, state management, mock server.
|
|
23
|
+
- `contract`: request/response fields, error codes, permission responses.
|
|
24
|
+
- `e2e`: cross-page flows, login, permissions, critical business loops.
|
|
25
|
+
- `smoke`: key pages or happy paths do not crash.
|
|
26
|
+
- `browser-acceptance`: real browser interaction, feedback location, responsive and visual state.
|
|
27
|
+
- `security-review`: permissions, sensitive information, authorization bypass, duplicate submit, injection risk.
|
|
@@ -1,48 +1,48 @@
|
|
|
1
1
|
# OpenTest-Driven Development
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## Positioning
|
|
4
4
|
|
|
5
|
-
OpenTest-driven development
|
|
5
|
+
OpenTest-driven development is not a replacement name for traditional TDD. It places TDD inside a broader quality evidence chain: first mine implicit scenarios and build a risk matrix, then decide which behavior is proven by unit, component, integration, contract, E2E, smoke, browser acceptance, or security review evidence.
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## Why Not Just TDD
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Traditional TDD can easily cover only explicit requirements and happy paths. Real product behavior also includes:
|
|
10
10
|
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
-
|
|
11
|
+
- Empty input, invalid input, and field dependencies.
|
|
12
|
+
- Network failures, server failures, expired auth, and missing permissions.
|
|
13
|
+
- Whether error feedback appears below a field, at the top of a form, in a toast, in a modal, or in a page error region.
|
|
14
14
|
- loading、empty、retry、disabled、submitting、long content、mobile。
|
|
15
|
-
-
|
|
15
|
+
- Cross-page navigation, return restoration, data refresh, and duplicate submission.
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
These scenarios should enter the acceptance-to-test matrix before evidence layers are selected.
|
|
18
18
|
|
|
19
|
-
##
|
|
19
|
+
## Recommended Order
|
|
20
20
|
|
|
21
21
|
```text
|
|
22
|
-
|
|
23
|
-
-> OpenTest plan:
|
|
24
|
-
-> OpenTest author:
|
|
25
|
-
-> build:
|
|
26
|
-
-> OpenTest run:
|
|
27
|
-
-> OpenTest accept:
|
|
28
|
-
-> OpenTest verify:
|
|
22
|
+
Requirement / OpenSuper design
|
|
23
|
+
-> OpenTest plan: implicit scenarios + risk + evidence layers
|
|
24
|
+
-> OpenTest author: test assets and natural language acceptance
|
|
25
|
+
-> build: implement against the matrix
|
|
26
|
+
-> OpenTest run: run project commands
|
|
27
|
+
-> OpenTest accept: real acceptance
|
|
28
|
+
-> OpenTest verify: quality gate report
|
|
29
29
|
-> OpenSuper verify/archive
|
|
30
30
|
```
|
|
31
31
|
|
|
32
|
-
##
|
|
32
|
+
## Login Example
|
|
33
33
|
|
|
34
|
-
| ID |
|
|
34
|
+
| ID | Intent | Trigger/Input | Expected behavior | Risk | Evidence layer | Required evidence | Status |
|
|
35
35
|
| --- | --- | --- | --- | --- | --- | --- | --- |
|
|
36
|
-
| ACC-001 |
|
|
37
|
-
| ACC-002 |
|
|
38
|
-
| ACC-003 |
|
|
39
|
-
| ACC-004 |
|
|
40
|
-
| ACC-005 |
|
|
41
|
-
| ACC-006 |
|
|
42
|
-
|
|
43
|
-
##
|
|
44
|
-
|
|
45
|
-
-
|
|
46
|
-
- blocked
|
|
47
|
-
- high-risk
|
|
48
|
-
-
|
|
36
|
+
| ACC-001 | Valid account logs in successfully | Valid username and password | Redirect to target page and establish session | high | e2e | Login flow acceptance | pending |
|
|
37
|
+
| ACC-002 | Username is empty | Empty username plus any password | Show username field error and do not send request | medium | component | Form test or UI acceptance | pending |
|
|
38
|
+
| ACC-003 | Password is wrong | Valid username plus wrong password | Show auth failure at form level or near password, preserving username | high | integration | API mock plus UI acceptance | pending |
|
|
39
|
+
| ACC-004 | Network is disconnected | Login request network failure | Show network error and retry, without misreporting password failure | high | e2e | Network failure acceptance | pending |
|
|
40
|
+
| ACC-005 | Submit clicked repeatedly | Click submit again while request is in flight | Button shows loading and duplicate submit is prevented | medium | component | UI state test | pending |
|
|
41
|
+
| ACC-006 | Token expires | Visit protected page | Return to login and preserve source path | high | e2e | Session expiry acceptance | pending |
|
|
42
|
+
|
|
43
|
+
## Output Requirements
|
|
44
|
+
|
|
45
|
+
- Every required scenario must have an evidence layer and execution surface.
|
|
46
|
+
- blocked is not pass; it must include a reason and recovery path.
|
|
47
|
+
- Missing evidence for high-risk scenarios defaults to fail unless the user explicitly accepts the risk and the reason is written down.
|
|
48
|
+
- Product behavior failure must not be hidden by heal; return to implementation or requirement correction.
|