camunda / camunda/api-test-generator
How do we calculate the test coverage of an API?
@esraagamal6 is already working on this.
Since May 18, 2026.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 3
- Avg merge
- 13h 41m
- Merged PRs (30d)
- 23
Description
100% negative request validation coverage
- What does exhaustive request validation coverage look like? Is it possible to get guarantee exhaustive coverage?
- What is the current negative request validation coverage of the OCA API via the request-validation generated tests?
- What categories are missing? And thus, what is the percentage of total coverage that we have currently?
Positive test coverage
How do we compute positive test coverage?
How much of it is operation level?
How much and how does it depend on business logic?
At the moment we generate base feature tests, which call the endpoint with required semantic inputs and assert success response code.
Then we have the variant suite that calls it with optional fields populated. How many, what combination? What business rules need to be expressed?
If we have the semantic graph and the business rules in the ontology, can we calculate the entire combinatorial space?
How do we design high value business logic tests for an endpoint? Ranges, state transitions, etc.
This intersects with the analysis from https://github.com/camunda/api-test-generator/issues/275
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.