@@ -72,7 +72,7 @@ produced in layer 1. No copying or re-parsing occurs; the underlying Bazel
7272action cache entry is reused.
7373
7474A ` filegroup ` named ` case_data ` then bundles the ` fbs ` target together with the
75- static fixture files (` architecture.json ` , ` expected.json ` or ` expected.yaml ` ),
75+ static fixture files (` architecture.json ` and ` expected.yaml ` ),
7676making the whole case available as a single Bazel dependency.
7777
7878For ` ComponentInternalApi ` and ` SequenceInternalApi ` suites, cases include
@@ -96,7 +96,7 @@ The shared `test_framework` library provides the following helpers:
9696| Helper | Description |
9797| --------| -------------|
9898| ` collect_case_fbs_files(suite, case, category) ` | Returns sorted absolute paths to every ` .fbs.bin ` in a category subdirectory |
99- | ` load_expected_fixture(suite, case) ` | Deserializes ` expected.json ` into ` ExpectedFixture ` |
99+ | ` load_expected_fixture(suite, case) ` | Deserializes ` expected.yaml ` into ` ExpectedFixture ` |
100100| ` load_expected_yaml_fixture(suite, case) ` | Deserializes ` expected.yaml ` into ` ExpectedFixture ` |
101101| ` run_validation_profile(case_name, profile, input_bundle) ` | Writes a profile-owned input bundle, spawns the CLI binary, and returns ` CliRunResult ` |
102102| ` assert_cli_result(case, expected, result) ` | Asserts exit code and checks each string in ` error_contains ` against the log |
@@ -120,7 +120,7 @@ design/component_diagram.fbs.bin ← in ArchitecturalDesignInfo.static
120120component/component_diagram.fbs.bin ← symlink → file above
121121
122122 │ filegroup case_data
123- │ → bundles fbs + architecture.json + expected.json
123+ │ → bundles fbs + architecture.json + expected.yaml
124124 ▼
125125//.../bazel_component:bazel_component_test_data ← aggregated across all cases
126126
@@ -149,7 +149,7 @@ the validator under test.
149149├── BUILD # architectural_design + provider_fbs_fixture_bundle + case_data
150150├── component_diagram.puml
151151├── architecture.json # Bazel build-graph snapshot (components/units)
152- └── expected.json
152+ └── expected.yaml
153153```
154154
155155### ComponentClass cases
@@ -159,7 +159,7 @@ the validator under test.
159159├── BUILD # architectural_design + unit_design + provider_fbs_fixture_bundle + case_data
160160├── component_diagram.puml
161161├── class_diagram.puml # one or more; multi-file: class_diagram_part1.puml, ...
162- └── expected.json
162+ └── expected.yaml
163163```
164164
165165### ClassDesignImplementation cases
@@ -180,7 +180,7 @@ the validator under test.
180180├── BUILD # architectural_design + provider_fbs_fixture_bundle + case_data
181181├── component_diagram.puml
182182├── sequence_diagram.puml
183- └── expected.json
183+ └── expected.yaml
184184```
185185
186186### ComponentInternalApi cases
@@ -190,7 +190,7 @@ the validator under test.
190190├── BUILD # architectural_design + provider_fbs_fixture_bundle + case_data
191191├── component_diagram.puml
192192├── internal_api_diagram.puml
193- └── expected.json
193+ └── expected.yaml
194194```
195195
196196### SequenceInternalApi cases
@@ -201,16 +201,13 @@ the validator under test.
201201├── component_diagram.puml
202202├── sequence_diagram.puml
203203├── internal_api_diagram.puml
204- └── expected.json
204+ └── expected.yaml
205205```
206206
207- ### ` expected.json ` / ` expected. yaml` format
207+ ### ` expected.yaml ` format
208208
209- ``` json
210- {
211- "should_pass" : true ,
212- "error_contains" : []
213- }
209+ ``` yaml
210+ should_pass : true
214211` ` `
215212
216213| Field | Type | Description |
@@ -220,9 +217,7 @@ the validator under test.
220217
221218The framework uses **substring matching** for `error_contains`, so entries do
222219not need to reproduce exact formatting — just enough context to uniquely
223- identify the error. Existing suites use ` expected.json ` ; the
224- ` class_design_implementation ` suite uses ` expected.yaml ` so larger multi-line
225- error fragments stay readable.
220+ identify the error.
226221
227222# # Running the tests
228223
@@ -236,7 +231,6 @@ Run a single suite:
236231
237232` ` ` bash
238233bazel test //validation/core/integration_test/bazel_component:integration_test
239- bazel test //validation/core/integration_test/component_class:integration_test
240234bazel test //validation/core/integration_test/component_sequence:integration_test
241235bazel test //validation/core/integration_test/component_internal_api:component_internal_api_integration_test
242236bazel test //validation/core/integration_test/sequence_internal_api:sequence_internal_api_integration_test
@@ -253,16 +247,15 @@ bazel test //validation/core/integration_test/class_design_implementation:integr
2532472. Add the `.puml` source file(s) and — for `bazel_component` — an
254248 ` architecture.json` .
255249
256- 3 . Write ` expected.json ` or ` expected. yaml` . For negative cases add the error
250+ 3. Write `expected.yaml`. For negative cases add the error
257251 substrings you expect to see in the CLI log.
258252
2592534. Create a `BUILD` file following the pattern of an existing case in the same
260254 suite.
261255
2622565. Add the new `case_data` target to the matching filegroup in
263257 [`BUILD`](BUILD) (`bazel_component_test_data`,
264- ` component_class_test_data ` , ` component_sequence_test_data ` ,
265- ` component_internal_api_test_data ` , ` sequence_internal_api_test_data ` ,
258+ ` component_sequence_test_data` , `component_internal_api_test_data`, `sequence_internal_api_test_data`,
266259 or `class_design_implementation_test_data`).
267260
2682616. Add a `#[test]` function in the matching suite file, such as
0 commit comments