validate S3 client

[sullis]

No description provided.

[wakingrufus]

what is the benefit of these additional assertions / s3 calls? It seems like it just testing AWS code, not spring-funk code

[sullis]

what is the benefit of these additional assertions / s3 calls? It seems like it just testing AWS code, not spring-funk code

I am evaluating Amazon's CRT client:

#64

I wanted to have baseline tests for the S3AsyncClient. S3TestHelper helps validate that the CRT client behaves the same as the Netty client.

[wakingrufus]

what is the benefit of these additional assertions / s3 calls? It seems like it just testing AWS code, not spring-funk code

I am evaluating Amazon's CRT client:

#64

I wanted to have baseline tests for the S3AsyncClient. S3TestHelper helps validate that the CRT client behaves the same as the Netty client.

I see. this CRT client is new to me. I think i have an idea:
let's not repeat these assertions for every test. but let's keep them in the test with metrics test. but then we can add to them to pull the metrics for the operations out of the meter registry. that can establish a baseline for performance, then when we switch to CRT, we can compare the metrics that come out and make sure they are at least as good as they were with Netty. (obviously these will not be real performance metrics, as we will keep it fast and small, but its somthing).

OR

we can add a configuration property to select the client, and replicate the test with metrics for both variants. that way downstream consumers can select the impl that best fits their use case and we can still collect performance metrics for each.

[sullis]

This blog post (February 2023) compares the CRT client with the Netty client:

https://aws.amazon.com/blogs/developer/announcing-availability-of-the-aws-crt-http-client-in-the-aws-sdk-for-java-2-x/

[sullis]

This PR is not necessary.

I have a test suite in a different repo:
https://github.com/sullis/s3-playground/tree/main/src/test/java/io/github/sullis/s3/playground