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
{{ message }}
Repository navigation
Commit 3c93b0c
Browse filesBrowse the repository at this point in the historyBrowse files
Add ConfigurationFlatbufferParsingStrategy
+ Parse mw_com config from a FlatBuffers binary into the
impl::Configuration model
+ Declare optional/@required scalars as `= null` in mw_com_config.fbs so
the parser can tell a missing value from a default
+ Move the generated fbs types into the configuration::fbs namespace
+ Add unit tests and an optional-scalars example config
+ Patch the flatc-generated header to call `this->B()` so it compiles:
flatc's `B` template parameter hides the field accessor `B()` in
AllowedConsumer/AllowedProvider
Common test to run on json configs
+ If flatbuffers flag is enabled, json_to_flatbuffer converter is
generating config bins for all the possible testcases, and the common
test is done on both
+ Ensures the integrity of the json_to_flatbuffer converter and the same
results from both parsing mechanisms
+ Redundant tests removed - Edge cases covered
| No FlatBuffers dependency is linked; `ConfigurationFlatbufferParsingStrategy::Parse()` logs a fatal error and terminates |`SCORE_MW_COM_FLATBUFFERS_CONFIGURATION_ENABLED` is defined and the strategy is implemented |
117
+
|`configuration_parsing_strategy_test` runs the JSON strategy only | It runs every parametrised test for JSON **and** FlatBuffer |
118
+
| FlatBuffer-only targets (`mw_com_config_fbs`, `configuration_flatbuffer_parsing_strategy_test`, ...) are incompatible and skipped | They are built and run |
119
+
120
+
Not gated by the flag: `generate_schema`, `schema_drift_test` and the `json_to_flatbuffer` conversion of the test
121
+
configurations. These rules only need `flatc` as a build tool.
122
+
123
+
Because a plain `bazel test` silently skips the FlatBuffer side, always run the tests **with and without**
124
+
`--config=flatbuffers` after a schema change.
125
+
126
+
## Tests
127
+
128
+
Parser test configurations live in [test/parsing_strategy_configs](./test/parsing_strategy_configs), one file per
129
+
case, and are registered in its [BUILD](./test/parsing_strategy_configs/BUILD) file in one of two lists.
130
+
131
+
### `SHARED_CONFIGS`: tested with both strategies
132
+
133
+
Every `<name>.json` is also converted to `<name>.bin` at build time via `json_to_flatbuffer`. The parametrised suites
134
+
in [configuration_parsing_strategy_test.cpp](./configuration_parsing_strategy_test.cpp)
135
+
(`ConfigurationParsingStrategyTest` & co., instantiated with `kStrategies`) parse the `.json` with the JSON strategy
136
+
and the `.bin` with the FlatBuffer strategy, then check that both produce the same result or both terminate. This is
137
+
the default: one input, two parsers, one expectation.
138
+
139
+
Use it for every configuration that flatc can convert. This includes *semantically* invalid configurations (missing
140
+
required keys, duplicates, inconsistent values), because those must be rejected by both parsers.
141
+
142
+
### `FLATC_REJECTED_CONFIGS`: tested with the JSON strategy only
143
+
144
+
Some invalid configurations can't be converted by flatc at all: unknown keys, wrong JSON types, unknown enum
145
+
symbols, numbers outside the type's range. No `.bin` can be built for them, so the FlatBuffer strategy never sees such
146
+
input. They are covered as follows:
147
+
148
+
-**JSON path:** the JSON strategy must reject them at runtime. They are tested in
149
+
`ConfigurationJsonOnlyParsingTest` (plain `TEST_F`, no strategy parameter, using `ParseJson()`).
150
+
-**FlatBuffer path:** a `<name>_schema_rejects` test (`validate_json_schema_test` with `expected_failure = True`)
151
+
checks that the JSON schema generated from the `.fbs` rejects the config.
152
+
153
+
The schema test stands in for "flatc rejects it" because flatc is only used through baselibs *build* rules. A
154
+
rejected input fails the build action, and Bazel can't turn a failing action into a passing test.
155
+
`rules_build_error` only supports C++ targets. A TODO in the BUILD file tracks replacing these schema tests with
156
+
build-failure tests once that is possible.
157
+
158
+
The schema is **stricter** than flatc (required keys, `@min`/`@max`). The schema rejecting a config therefore
159
+
doesn't mean flatc rejects it. Before putting a config into `FLATC_REJECTED_CONFIGS`, make sure `json_to_flatbuffer`
160
+
really fails to build it. Otherwise it belongs in `SHARED_CONFIGS`, so that the FlatBuffer strategy's runtime
0 commit comments