4 ms·
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 for
by shireboy 4y ago
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 4y agoWow very interesting! Did you manage to play it back manually and/or via tests? I ran into unexpected challenges while doing this.
- shireboy 4y agoYes, 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.