Skip to content
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.

Sign up for GitHub

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

Fix some RestJson query string protocol request tests for servers #1040

Merged
merged 1 commit into from
Feb 21, 2022
Merged

Fix some RestJson query string protocol request tests for servers #1040

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Fix some RestJson query string protocol request tests for servers 
From a server perspective, `params` is the expected output after request
deserialization. Since `queryParamsMapOfStringList` is bound with
`@httpQueryParams` to the query string, its value must be present and
derived from the input `queryParams` field of the request test.
  • Loading branch information
@david-perez
david-perez committed Jan 7, 2022
commit 2d48d2eba83e461d9007d97545829800b81c495c
12 changes: 12 additions & 0 deletions smithy-aws-protocol-tests/model/restJson1/http-query.smithy
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,10 @@ apply AllQueryStringTypes @httpRequestTests([
params: {
queryFloat: "NaN",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test doesn't make sense from the server perspective anyway, since in IEEE 754 floating point numbers, NaN != NaN. As such, what should we assert we received after request deserialization, if we can't compare the deserialized value to anything? Shall I tag this test so that it only applies to the client, or should I assert something special in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavior that nan isn't equal to nan is only important when you're using actual numbers for number things. Here we are asserting that the result is NaN instead of 0, +Inf, -Inf, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JordonPhillips I think what you're saying is that a protocol test involving NaN only cares that the deserialized value is a NaN and that we shouldn't compare the bits, right? That's the approach we took https://docs.rs/aws-smithy-protocol-test/latest/aws_smithy_protocol_test/trait.FloatEquals.html, let me know if something else should be asserted.

In any case, this is subtle and should be called out in the documentation, perhaps in this page? https://awslabs.github.io/smithy/1.0/spec/http-protocol-compliance-tests.html

queryDouble: "NaN",
queryParamsMapOfStringList: {
"Float": ["NaN"],
"Double": ["NaN"],
}
}
},
{
Expand All @@ -155,6 +159,10 @@ apply AllQueryStringTypes @httpRequestTests([
params: {
queryFloat: "Infinity",
queryDouble: "Infinity",
queryParamsMapOfStringList: {
"Float": ["Infinity"],
"Double": ["Infinity"],
}
}
},
{
Expand All @@ -171,6 +179,10 @@ apply AllQueryStringTypes @httpRequestTests([
params: {
queryFloat: "-Infinity",
queryDouble: "-Infinity",
queryParamsMapOfStringList: {
"Float": ["-Infinity"],
"Double": ["-Infinity"],
}
}
},
])
Expand Down