[FEATURE REQ] Investigate Playback and record system about azure-sdk-for-c HOT 6 CLOSED

But I think that we should set the goals by "make sure we verify X", instead of "make sure we use response playback/record".

What we want is the ability to run "live tests" without needing the actual endpoint. The framework also doubles as a tracing mechanism as customers can turn it on to log what went in and what came out.

from azure-sdk-for-c.

There should be an agent listening to requests and based on previous cached responses from the live service, return back the expected response.

On option is to run the tests to the actual endpoint, and record the results, ~once a week, to stay up to date.

This reduces cost and improves testing performance.

from azure-sdk-for-c.

@RickWinter , we should only create one playback-record test framework for C++ and see if we can reuse it here.

from azure-sdk-for-c.

I think we should have live tests + unit tests, and NOT have response recorder.
For the response recorder, we need to filter out secrets from the recorded responses, and understand timestamps. And two - it won't be possible to have request-to-response map for some cases, when on a second try, the service is supposed to give another reply for exactly the same request.
Look at what we need, and if we are achieving the goals that we set, regardless of the technology used, versus what shiny technology can we use, if it can enable no new scenarios.
I also think that checking in responses is going to turn tests into a harder to understand and manage repo, where it is hard to track everything that is happening or is supposed to happen.
I understand that in other languages, you get frameworks, so it is cheap to enable it, but if we are supposed to write playback/record engine ourselves, I don't think it is worth it. It needs to take care of secret filtering, timestamp handling, and failures need to be easily debuggable.
I think that writing all that by ourselves is a bad idea. The only possible option I see is to write a wrapper that makes interop calls for the .NET/Java record/playback engine that is already written (we can write a transport adapter doing that).
But I think that we should set the goals by "make sure we verify X", instead of "make sure we use response playback/record".

from azure-sdk-for-c.

Labeling this one "Client" since this is about finding a solution for C. Agreed it's possible the shared test proxy service may be a solution here.

from azure-sdk-for-c.

Hi @gilbertw, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.

from azure-sdk-for-c.