-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor and DRY up protocol test generation #3713
Refactor and DRY up protocol test generation #3713
Conversation
Protocol test generation code was one of the earlier parts of smithy-rs's codebase and it has accrued a fair amount of tech debt as we have evolved the code generation primitives. Its code was also forked when the server code generator was introduced, introducing a lot of duplicated code that has deviated over time. This commit refactors the code to modern standards and aims to reconcile commonalities in `ProtocolTestGenerator`, so that both client and server can reap centralized improvements over time.
A new generated diff is ready to view.
A new doc preview is ready to view. |
...software/amazon/smithy/rust/codegen/core/smithy/generators/protocol/ProtocolTestGenerator.kt
Outdated
Show resolved
Hide resolved
...software/amazon/smithy/rust/codegen/core/smithy/generators/protocol/ProtocolTestGenerator.kt
Show resolved
Hide resolved
if (runOnly.isEmpty()) { | ||
this.filter { testCase -> testCase.protocol == codegenContext.protocol && !disabledTests.contains(testCase.id) } | ||
} else { | ||
this.filter { testCase -> runOnly.contains(testCase.id) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out aloud: Should we print to console that we are only running the runOnly
set of test cases. In future, we might forget that there is an entry in runOnly
and wonder why the test cases are not being executed.
...software/amazon/smithy/rust/codegen/core/smithy/generators/protocol/ProtocolTestGenerator.kt
Show resolved
Hide resolved
?.getTestCasesFor(appliesTo).orEmpty().map { TestCase.ResponseTest(it, outputShape) } | ||
val responseTestsOnErrors = | ||
operationIndex.getErrors(operationShape).flatMap { error -> | ||
val testCases = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Just a style guide issue. Both requestTests
and responseTestsOnOperations
do not define a temporary variable testCases
and then apply .map
on that variable. They invoke map
function directly:
error.getTrait<HttpResponseTestsTrait>()
?.getTestCasesFor(appliesTo).orEmpty().map { TestCase.ResponseTest(it, error) }
* Parses from the model and returns all test cases for [operationShape] applying to the [appliesTo] artifact type | ||
* that should be rendered by implementors. | ||
**/ | ||
fun allTestCases(appliesTo: AppliesTo): List<TestCase> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we rename this to allMatchingTestCases
since it filters before returning?
const val AWS_QUERY = "aws.protocoltests.query#AwsQuery" | ||
const val EC2_QUERY = "aws.protocoltests.ec2#AwsEc2" | ||
const val REST_JSON_VALIDATION = "aws.protocoltests.restjson.validation#RestJsonValidation" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we need one for CBOR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume it'll be added in the CBOR PR once this PR has been merged to main and then the CBOR PR merges the latest main into it (since this PR is refactoring w.r.t the main branch, it's probably supposed to not know about CBOR 🙂)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, some of these are unused. We only need to refer to service shapes containing failing test cases. I've removed the unused ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, from a client perspective. Thanks for factoring out common pieces!
…refactor-protocol-test-generation
A new generated diff is ready to view.
A new doc preview is ready to view. |
RPC v2 CBOR is a new protocol that ~is being added~ has [recently been added](https://smithy.io/2.0/additional-specs/protocols/smithy-rpc-v2.html) to the Smithy specification. _(I'll add more details here as the patchset evolves)_ Credit goes to @jjant for initial implementation of the router, which I built on top of from his [`jjant/smithy-rpc-v2-exploration`](https://github.com/awslabs/smithy-rs/tree/jjant/smithy-rpc-v2-exploration) branch. Tracking issue: #3573. ## Caveats `TODO`s are currently exhaustively sprinkled throughout the patch documenting what remains to be done. Most of these need to be addressed before this can be merged in; some can be punted on to not make this PR bigger. However, I'd like to call out the major caveats and blockers here. I'll keep updating this list as the patchset evolves. - [x] RPC v2 has still not been added to the Smithy specification. It is currently being worked on over in the [`smithy-rpc-v2`](https://github.com/awslabs/smithy/tree/smithy-rpc-v2) branch. The following are prerrequisites for this PR to be merged; **until they are done CI on this PR will fail**: - [x] Smithy merges in RPC v2 support. - [x] Smithy releases a new version incorporating RPC v2 support. - Released in [Smithy v1.47](https://github.com/smithy-lang/smithy/releases/tag/1.47.0) - [x] smithy-rs updates to the new version. - Updated in #3552 - [x] ~Protocol tests for the protocol do not currently exist in Smithy. Until those get written~, this PR resorts to Rust unit tests and integration tests that use `serde` to round-trip messages and compare `serde`'s encoders and decoders with ours for correctness. - Protocol tests are under the [`smithy-protocol-tests`](https://github.com/smithy-lang/smithy/tree/main/smithy-protocol-tests/model/rpcv2Cbor) directory in Smithy. - We're keeping the `serde_cbor` round-trip tests for defense in depth. - [ ] #3709 - Currently only server-side support has been implemented, because that's what I'm most familiar. However, we're almost all the way there to add client-side support. - ~[ ] [Smithy `document` shapes](https://smithy.io/2.0/spec/simple-types.html#document) are not supported. RPC v2's specification currently doesn't indicate how to implement them.~ - [The spec](https://smithy.io/2.0/additional-specs/protocols/smithy-rpc-v2.html#shape-serialization) ended up leaving them as unsupported: "Document types are not currently supported in this protocol." ## Prerequisite PRs This section lists prerequisite PRs and issues that would make the diff for this one lighter or easier to understand. It's preferable that these PRs be merged prior to this one; some are hard prerequisites. They mostly relate to parts of the codebase I've had to touch or ~pilfer~ inspect in this PR where I've made necessary changes, refactors and "drive-by improvements" that are mostly unrelated, although some directly unlock things I've needed in this patchset. It makes sense to pull them out to ease reviewability and make this patch more semantically self-contained. - #2516 - #2517 - #2522 - #2524 - #2528 - #2536 - #2537 - #2531 - #2538 - #2539 - #2542 - #3684 - #3678 - #3690 - #3713 - #3726 - #3752 ## Testing <!--- Please describe in detail how you tested your changes --> <!--- Include details of your testing environment, and the tests you ran to --> <!--- see how your change affects other areas of the code, etc. --> ~RPC v2 has still not been added to the Smithy specification. It is currently being worked on over in the [`smithy-rpc-v2`](https://github.com/awslabs/smithy/tree/smithy-rpc-v2) branch.~ This can only be tested _locally_ following these steps: ~1. Clone [the Smithy repository](https://github.com/smithy-lang/smithy/tree/smithy-rpc-v2) and checkout the `smithy-rpc-v2` branch. 2. Inside your local checkout of smithy-rs pointing to this PR's branch, make sure you've added `mavenLocal()` as a repository in the `build.gradle.kts` files. [Example](8df82fd). 4. Inside your local checkout of Smithy's `smithy-rpc-v2` branch: 1. Set `VERSION` to the current Smithy version used in smithy-rs (1.28.1 as of writing, but [check here](https://github.com/awslabs/smithy-rs/blob/main/gradle.properties#L21)). 2. Run `./gradlew clean build pTML`.~ ~6.~ 1. In your local checkout of the smithy-rs's `smithy-rpc-v2` branch, run `./gradlew codegen-server-test:build -P modules='rpcv2Cbor'`. ~You can troubleshoot whether you have Smithy correctly set up locally by inspecting `~/.m2/repository/software/amazon/smithy/smithy-protocols-traits`.~ ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [ ] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._
Protocol test generation code was one of the earlier parts of
smithy-rs's codebase and it has accrued a fair amount of tech debt as we
have evolved the code generation primitives. Its code was also forked
when the server code generator was introduced, introducing a lot of
duplicated code that has deviated over time.
This commit refactors the code to modern standards and aims to reconcile
commonalities in
ProtocolTestGenerator
, so that both client and servercan reap centralized improvements over time.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.