[shireboy]

I just this week did something similar for a line of business app API I'm migrating. I added code to the API to record all unique requests to a .http/.rest format file (natively supported in vlatest Visual Studio 22 and via extension in VS Code). I can then play those back manually or via automated integration tests that read the .http files. Yes, I'm hand-waving over authentication and downstream database and 3rd party APIs, but overall it's working well to quickly test against tons of production-like API calls.

[vedant_ag]

Wow very interesting!

Did you manage to play it back manually and/or via tests? I ran into unexpected challenges while doing this.

[shireboy]

Yes, I have it set up where I can play the tests manually via the .http file or automated via a test suite. In general, I parse the .http file- each ### represents a new test, next line is METHOD URL, next lines are headers, empty space, then request body. Would vary based on test framework, but for mstest, it looks like this:

[DataTestMethod] [DynamicData(nameof(GetAllHttpTests), DynamicDataSourceType.Method, DynamicDataDisplayName = nameof(GetTestDisplayName))] public async Task RunHttpTests(string endpoint, string method, string data){...}

To be clear, this is integration testing, not unit. Testing that certain HTTP requests work, not necessarily that they are correct.