What’s the hardest part of testing an existing API from its codebase?

by

I’m built version 1 of Sydes-test, an open-source CLI that reads backend code repo of your REST API(s) and generates its contracts, test cases converting to Postman collections. You can directly import those postman collection and run according to your hosted API location. When API code changes, you can rerun just one command for the affected API and generate new testcases.

The idea came from a simple problem: for an existing API, the contract is usually scattered across routes, handlers, validators, models, and response logic.

I’d love to understand where this is most painful for others or even if you think this is not a problem at all, do let me know.

What usually takes the most time when you need to test an existing API?

- Finding the right route and handler

- Understanding required fields and validation rules

- Figuring out expected responses

- Creating edge cases

- Keeping Postman collections up to date

- Something else

- This is not a problem at all?

Also curious whether you would use a tool like this locally, in CI, or as part of a coding-agent workflow.

Note: The future plan is to go deep into code and come up with more test cases, figure out side-effects, blast radius of changes and any bugs in the API code.

1 view

Add a comment

Replies

Be the first to comment