test: convert router v1 JSON test configs to v2 YAML#6332
test: convert router v1 JSON test configs to v2 YAML#6332mattklein123 merged 9 commits intoenvoyproxy:masterfrom
Conversation
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
|
hmm the two tests I switched to These seem like good test cases to retain, but wasn't sure whether to
|
|
@derekargueta you are a hero, that's all I have to say. |
|
So my update here: still a bit stuck on those 2 tests, trying to get them to throw exceptions again. It seems that the protobuf validation get's executed when running
So my question (I suppose for @snowp) is am I moving in the right direction? Do we want to validate protobuf constraints as part of config tests? If we don't run validation, then malformed configs pass to |
|
FWIW the HCM config tests (my next target) are in a similar state - v1 JSON test configs that will throw errors during the v1-v2 translation phase, not protobuf validation. |
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
|
Figured out how to apply proto validation here, so we should be green-light for test parity without relying on the exceptions thrown during the v1->v2 translation. |
|
/retest |
|
🙀 failed invoking rebuild of |
snowp
left a comment
There was a problem hiding this comment.
Thanks, this looks great. Few comments/questions
| TestEnvironment::writeStringToFileForTest("direct_response_body", "Example text 3"); | ||
|
|
||
| // A superset of v1_json, with API v2 direct-response configuration added. | ||
| static const std::string v2_yaml = R"EOF( |
There was a problem hiding this comment.
minor nit but maybe this shouldn't reference v2 anymore?
|
|
||
| TestConfigImpl v2_yaml_config(parseRouteConfigurationFromV2Yaml(v2_yaml), factory_context_, true); | ||
| testConfig(v2_yaml_config, true); | ||
| testConfig(v2_yaml_config); |
There was a problem hiding this comment.
Since this is only invoked once now, maybe inline the lambda?
| route: | ||
| cluster: some-cluster | ||
| idle_timeout: 0s | ||
| idle_timeout: 1s |
There was a problem hiding this comment.
Why did this change? Validation?
There was a problem hiding this comment.
Yes, protobuf validation. (I'm no protobuf expert, but appears (validate.rules).duration.gt = {} is equivalent to > 0?)
I'm actually going to change this back to zero, but use EXPECT_THROW instead as that's the new expected behavior in v2. (ExplicitIdleTimeout below already tests a good idle_timeout so this test would be redundant)
Signed-off-by: Derek Argueta <dereka@pinterest.com>
mattklein123
left a comment
There was a problem hiding this comment.
Thanks, so amazing. One question.
/wait-any
| EXPECT_THROW_WITH_MESSAGE( | ||
| TestConfigImpl(parseRouteConfigurationFromJson(json), factory_context_, true), EnvoyException, | ||
| "routes must have redirect or one of cluster/cluster_header/weighted_clusters") | ||
| EXPECT_THROW(TestConfigImpl(parseRouteConfigurationFromV2Yaml(yaml), factory_context_, true), |
There was a problem hiding this comment.
Did this change because it's now handled by validation? Is it possible to include the validation error message? Same above?
There was a problem hiding this comment.
Ah yeah, forgot to come back to these after figuring out protobuf validation. Handled now. Using _WITH_REGEX with the critical message part since the protobuf errors are pretty verbose
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Signed-off-by: Derek Argueta <dereka@pinterest.com>
Description: This pull request converts all v1 JSON config test snippets to v2 YAML. There are multiple reasons for this:
parseRouteConfigurationFromV2Yaml)notes
TestBadCorsConfig, was removed in the process. It doesn't appear to violate any V2 API constraints so when passed through V2 parsing the test fails to throw any exceptions.BadRouteEntryConfigMissingPathSpecifierandBadRouteEntryConfigNoRedirectNoClusters, were swapped to useEXPECT_DEATHinstead ofEXPECT_THROW_WITH_MESSAGE. The exceptions previously thrown were part ofrds_json.ccwhen converting v1 to v2.Besides the above mentions, no test assertions were modified, only the test data to conform to v2.
Risk Level: Low
Docs Changes: No functional changes
Release Notes: No functional changes
Pt. 1/2 of #4616
Signed-off-by: Derek Argueta dereka@pinterest.com