You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The skeleton creation commit (guard-rail cutoff) is: cc6ba5d5
76
+
55
77
## Validation Rules
56
78
57
-
### Rule 1 — Every test must have a DisplayName
79
+
### Rule 1 -- Every test must have a DisplayName
58
80
Every `[Fact]` and `[Theory]` attribute MUST include a `DisplayName` parameter.
59
81
- FAIL: `[Fact]` without `DisplayName`
60
82
- FAIL: `[Theory]` without `DisplayName`
61
83
- PASS: `[Fact(DisplayName = "...")]`
62
84
63
-
### Rule 2 — RFC tag format
64
-
For files in RFC folders (`RFC1945/`, `RFC6265/`, `RFC7541/`, `RFC9110/`, `RFC9111/`, `RFC9112/`, `RFC9113/`, `RFC9114/`, `RFC9204/`), the DisplayName MUST match this regex pattern:
85
+
### Rule 2 -- RFC tag format
86
+
For files in RFC folders (RFC1945/, RFC6265/, RFC7541/, RFC9110/, RFC9111/, RFC9112/, RFC9113/, RFC9114/, RFC9204/), the DisplayName MUST match:
The RFC number in the DisplayName must match the folder the file resides in.
76
-
- PASS: File in `RFC9112/` has `"RFC9112-..."`
77
-
- FAIL: File in `RFC9112/` has `"RFC9113-..."` (wrong RFC)
98
+
- PASS: File in RFC9112/ has "RFC9112-..."
99
+
- FAIL: File in RFC9112/ has "RFC9113-..." (wrong RFC)
78
100
79
-
### Rule 4 — Consistent section within a file
80
-
All DisplayNames within a single test file should reference the same RFC section (the part after the RFC number). Mixed sections in one file are a warning.
81
-
- PASS: All tests in file use `RFC9112-3-RL-nnn`
82
-
- WARN: Same file has both `RFC9112-3-RL-001` and `RFC9112-5.4-HH-001` (mixed sections)
101
+
### Rule 4 -- Consistent section within a file
102
+
All DisplayNames within a single test file should reference the same RFC section. Mixed sections in one file are a warning.
103
+
- PASS: All tests in file use RFC9112-3-RL-nnn
104
+
- WARN: Same file has both RFC9112-3-RL-001 and RFC9112-5.4-HH-001 (mixed sections)
83
105
84
-
### Rule 5 — Consistent category code within a section group
106
+
### Rule 5 -- Consistent category code within a section group
85
107
Within a file, tests sharing the same RFC section should use the same category code.
86
-
- PASS: All `RFC9112-3-*` tests use `RL`
87
-
- WARN: `RFC9112-3-RL-001` and `RFC9112-3-XX-002` in same file (mixed categories)
108
+
- PASS: All RFC9112-3-* tests use RL
109
+
- WARN: RFC9112-3-RL-001 and RFC9112-3-XX-002 in same file (mixed categories)
88
110
89
-
### Rule 6 — Sequential numbering (no gaps, no duplicates)
90
-
Within each `(RFC, section, CAT)` group in a file:
111
+
### Rule 6 -- Sequential numbering (no gaps, no duplicates)
112
+
Within each (RFC, section, CAT) group in a file:
91
113
- Numbers must be unique (no duplicates)
92
114
- Numbers should be sequential starting from 001 (gaps are warnings, duplicates are errors)
93
-
- FAIL: Two tests with `RFC9112-3-RL-001` in the same file
94
-
- WARN: `RFC9112-3-RL-001` then `RFC9112-3-RL-003` (gap at 002)
115
+
- FAIL: Two tests with RFC9112-3-RL-001 in the same file
116
+
- WARN: RFC9112-3-RL-001 then RFC9112-3-RL-003 (gap at 002)
95
117
96
-
### Rule 7 — Global ID uniqueness
97
-
The full ID prefix `RFCxxxx-section-CAT-nnn` must be globally unique across ALL test files.
98
-
- FAIL: `RFC9112-3-RL-001` appears in two different files
118
+
### Rule 7 -- Global ID uniqueness
119
+
The full ID prefix RFCxxxx-section-CAT-nnn must be globally unique across ALL test files.
120
+
- FAIL: RFC9112-3-RL-001 appears in two different files
99
121
100
-
### Rule 8 — Description must not be empty
122
+
### Rule 8 -- Description must not be empty
101
123
The description part after the colon must contain at least one non-whitespace character.
102
-
- FAIL: `"RFC9112-3-RL-001: "`
103
-
- FAIL: `"RFC9112-3-RL-001:"`
124
+
- FAIL: "RFC9112-3-RL-001: "
125
+
- FAIL: "RFC9112-3-RL-001:"
104
126
105
-
## Workflow
127
+
### Rule 9 -- RFC Folder Guard-Rail (Warning Only -- Not a Blocker)
128
+
Any test file in a deprecated RFC*/ folder that was **added or modified after the skeleton
129
+
creation commit** (cc6ba5d5) triggers a warning. This is a guard-rail, not an error:
130
+
- Existing pre-skeleton RFC files: **no warning** (they pre-date the new structure)
131
+
- New files added to RFC*/ after skeleton: **WARN** with suggested new folder
132
+
- Files modified after skeleton in RFC*/: **WARN** with suggested new folder
106
133
107
-
### Step 1 — Collect all test files
134
+
The intent is to prevent the new-structure discipline from regressing. The build still passes;
135
+
the developer is informed and can choose to migrate the file.
108
136
109
-
Glob for all `*.cs`files under `src/TurboHttp.Tests/`.
137
+
**This rule does NOT apply to files in component-based folders** (Http2/, Semantics/, Cookies/, etc.).
110
138
111
-
### Step 2 — Extract all Fact/Theory attributes
139
+
##Workflow
112
140
113
-
For each test file, grep for `[Fact` and `[Theory` lines. Capture:
114
-
- File path
115
-
- Line number
116
-
- Whether DisplayName is present
117
-
- The full DisplayName string value (if present)
141
+
### Step 1 -- Collect all test files
142
+
Glob for all `*.cs` files under `src/TurboHttp.Tests/` and `src/TurboHttp.StreamTests/`.
118
143
119
-
### Step 3 — Classify files
144
+
### Step 2 -- Extract all Fact/Theory attributes
145
+
For each test file, grep for `[Fact` and `[Theory` lines. Capture file path, line number, DisplayName presence.
120
146
121
-
Determine if the file is in an RFC folder or a non-RFC folder:
0 commit comments