Skip to content

Stub out the HTTP client in aws_smithy_mocks_experimental #3926

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

Closed
ysaito1001 opened this issue Dec 2, 2024 · 0 comments · Fixed by #4098
Closed

Stub out the HTTP client in aws_smithy_mocks_experimental #3926

ysaito1001 opened this issue Dec 2, 2024 · 0 comments · Fixed by #4098

Comments

@ysaito1001
Copy link
Contributor

An SDK client created from mock_client does not stub out the HTTP client if used on it's own. This will result in real requests being sent to the service.

We should probably stub out the underlying HTTP client with infallible_client_fn.

github-merge-queue bot pushed a commit that referenced this issue May 5, 2025
## Motivation and Context
* #4074
* #3926

## Description
* Rename `aws-smithy-mocks-experimental` to `aws-smithy-mocks` and reset
version to `0.1.0`
* Fix [#3926](#3926) by
having `mock_client!` macro always set an HTTP client. By default it
returns a dummy I'm a teapot response to aid in debugging and be easy to
tell where that response is coming from. Also when a rule sets an HTTP
response it is not set as an extension in the request and returned by
the HTTP client. This allows for more thorough and accurate integration
testing as the client/runtime will see the response coming from the HTTP
client instead of being ignored and then replaced as it was before
* Added a new sequence builder API for allowing a rule to generate more
than one response. This allows for testing retries for example.
* Also deleted a hyper 1.x test that is no longer needed and was ignored
anyway

## Questions

* In this PR I've simply renamed/moved `aws-smithy-mocks-experimental`
to `aws-smithy-mocks`. Do we want or need to publish one last version of
`aws-smithy-mocks-experimental` with a deprecated API that instructs
users it has moved? Alternatively we could publish an [informational
advisory notice](https://github.com/RustSec/advisory-db#advisory-format)
about the rename. We don't currently promote the crate anywhere and the
dev guide will get updated so I'm on the fence for what we want to do.

## Testing
* Added new unit tests to exercise the API without needing an SDK client
by leveraging the manual `Operation` APIs.
* Added new integration tests for S3 to cover the macros and test the
library e2e.

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] For changes to the smithy-rs codegen or runtime crates, I have
created a changelog entry Markdown file in the `.changelog` directory,
specifying "client," "server," or both in the `applies_to` key.
- [x] For changes to the AWS SDK, generated SDK code, or SDK runtime
crates, I have created a changelog entry Markdown file in the
`.changelog` directory, specifying "aws-sdk-rust" in the `applies_to`
key.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
aws-sdk-rust-ci pushed a commit to awslabs/aws-sdk-rust that referenced this issue May 9, 2025
## Motivation and Context
* smithy-lang/smithy-rs#4074
* smithy-lang/smithy-rs#3926

## Description
* Rename `aws-smithy-mocks-experimental` to `aws-smithy-mocks` and reset
version to `0.1.0`
* Fix [#3926](smithy-lang/smithy-rs#3926) by
having `mock_client!` macro always set an HTTP client. By default it
returns a dummy I'm a teapot response to aid in debugging and be easy to
tell where that response is coming from. Also when a rule sets an HTTP
response it is not set as an extension in the request and returned by
the HTTP client. This allows for more thorough and accurate integration
testing as the client/runtime will see the response coming from the HTTP
client instead of being ignored and then replaced as it was before
* Added a new sequence builder API for allowing a rule to generate more
than one response. This allows for testing retries for example.
* Also deleted a hyper 1.x test that is no longer needed and was ignored
anyway

## Questions

* In this PR I've simply renamed/moved `aws-smithy-mocks-experimental`
to `aws-smithy-mocks`. Do we want or need to publish one last version of
`aws-smithy-mocks-experimental` with a deprecated API that instructs
users it has moved? Alternatively we could publish an [informational
advisory notice](https://github.com/RustSec/advisory-db#advisory-format)
about the rename. We don't currently promote the crate anywhere and the
dev guide will get updated so I'm on the fence for what we want to do.

## Testing
* Added new unit tests to exercise the API without needing an SDK client
by leveraging the manual `Operation` APIs.
* Added new integration tests for S3 to cover the macros and test the
library e2e.

## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] For changes to the smithy-rs codegen or runtime crates, I have
created a changelog entry Markdown file in the `.changelog` directory,
specifying "client," "server," or both in the `applies_to` key.
- [x] For changes to the AWS SDK, generated SDK code, or SDK runtime
crates, I have created a changelog entry Markdown file in the
`.changelog` directory, specifying "aws-sdk-rust" in the `applies_to`
key.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant