Ask HN: Implement API Testing on Legacy Codebases
3 comments
It should be possible to generate a Client from the Swagger (OpenAPI) specification. Pick a language you like, generate the client and setup the end-to-end (e2e) tests for the API.
In Go I do this for gRPC using the build-in unit tests of the language.
It'll be painful but once complete you can hammer away at the code with a sledgehammer and know you didn't break endpoints if the tests pass.
In Go I do this for gRPC using the build-in unit tests of the language.
It'll be painful but once complete you can hammer away at the code with a sledgehammer and know you didn't break endpoints if the tests pass.
Thank you so much for this!
I didn't realize Swagger/OpenAPI had a way to auto-generate its specification. Your comment led me down the rabbit hole and helped me to find a few options that might do the trick.
I didn't realize Swagger/OpenAPI had a way to auto-generate its specification. Your comment led me down the rabbit hole and helped me to find a few options that might do the trick.
Awesome I hope it works out for you!
I've recently been tasked with doing some code cleanup for a hefty .Net codebase. It quickly became apparent that this wasn't going to be possible without some sanity checks to make sure that my refactors didn't introduce any regressions.
I've been writing mini functional tests for each Swagger API endpoint using a custom Python script and some .json files. Ideally though, this feels like something that should be formalized and automated.*
Got any suggestions for a tool or approach?
---
*For context, the way this is currently done by other devs is opening up the Swagger web interface, manually entering some data, and checking the response.