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
@smokeTests is a great testing trait that should apply to my use case nicely as well (https://github.com/awslabs/smithy-dafny), but I had planned to use it to check that validation is happening correctly, and it turns out I can't do that because the trait validation asserts that params satisfies the traits like @required and constraint traits like @range on the operation's input shape, and the raised validation events are at the ERROR severity level so I can't suppress them.
I'd propose that the validation be loosened to only assert that the params node types are compatible with the input shape of the operation.
Two more minor points I'd like to address if possible:
I'd like to be able to state something like failure: {errorId: ValidationError}, but validation errors are not modeled so there's no such shape id to reference. Could we have an additional validationFailure: ... member for the Expectation union?
The documentation on params also states "Parameter values that contain binary data MUST be defined using values that can be represented in plain text as the plain text representation". That seems to have carried over from the HTTP protocol tests spec, but it feels less necessary here since we're not inspecting the Base64-encoded payloads, and in my case I'd love to be able to pass arbitrary binary data.
I'm willing to cut a PR if we agree on a solution. :)
The text was updated successfully, but these errors were encountered:
@smokeTests
is a great testing trait that should apply to my use case nicely as well (https://github.com/awslabs/smithy-dafny), but I had planned to use it to check that validation is happening correctly, and it turns out I can't do that because the trait validation asserts thatparams
satisfies the traits like@required
and constraint traits like@range
on the operation's input shape, and the raised validation events are at theERROR
severity level so I can't suppress them.I'd propose that the validation be loosened to only assert that the
params
node types are compatible with the input shape of the operation.Two more minor points I'd like to address if possible:
failure: {errorId: ValidationError}
, but validation errors are not modeled so there's no such shape id to reference. Could we have an additionalvalidationFailure: ...
member for theExpectation
union?params
also states "Parameter values that contain binary data MUST be defined using values that can be represented in plain text as the plain text representation". That seems to have carried over from the HTTP protocol tests spec, but it feels less necessary here since we're not inspecting the Base64-encoded payloads, and in my case I'd love to be able to pass arbitrary binary data.I'm willing to cut a PR if we agree on a solution. :)
The text was updated successfully, but these errors were encountered: