# OpenAPI IT Coverage Registry This registry records which Nacos HTTP APIs are covered by `test/openapi-test` integration tests and where to find the scenario matrix for each API surface. It is meant for maintainers and agents to quickly locate coverage before adding or debugging an IT. ## Maintenance Rules - Update the matching scenario document whenever an OpenAPI/AdminAPI/ConsoleAPI IT class is added, removed, or gains meaningful scenario coverage. - Keep the class Javadoc `Scenario coverage` section or the scenario document as the source of truth for what a class verifies. - Record API scenario coverage, not line or branch coverage. Each row should identify expected capability, boundary/validation, and exception/error handling coverage when those scenario groups are practical. - If an exposed success path is intentionally not executed because it mutates risky runtime or storage state, record the reason in the scenario cell. ## Status Legend | Status | Meaning | | --- | --- | | Covered | The current IT verifies the expected behavior and its important result shape. | | Partial | The current IT verifies representative behavior, but important public API scenarios remain. | | Pending | No IT currently verifies this public API scenario. | ## Coverage Calculation Coverage is calculated from the API-surface rows in the scenario documents. One row may cover multiple closely coupled HTTP operations in a workflow, such as a create/query/update/delete API group. Strict coverage counts only `Covered` rows. Effective coverage counts `Covered` rows as `1.0` and `Partial` rows as `0.5`. | API surface | Scenario rows | Covered | Partial | Pending | Strict coverage | Effective coverage | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | Client OpenAPI | 8 | 8 | 0 | 0 | 100.00% | 100.00% | | Admin API | 35 | 30 | 5 | 0 | 85.71% | 92.86% | | Console API | 27 | 25 | 2 | 0 | 92.59% | 96.30% | | Total | 70 | 63 | 7 | 0 | 90.00% | 95.00% | Partial rows are documented in the matching scenario document. The current partial set is limited to operations whose remaining success paths mutate shared runtime/storage state, require publish-pipeline plugin data, or require an external LLM provider. Plugin management API IT covers detail metadata, request validation, not-found responses, and rejection of config updates for non-configurable plugins. The runtime-configurable success path remains partial because the standalone test distribution currently has no built-in plugin implementing `PluginConfigSpec`; full-map replacement, source fallback, effect mode checks, masking, same-source sensitive value preservation, and retained-source apply failure/retry are covered in core unit tests. Config scenario rows cover the current 3.3 Config model. Blank or omitted namespace inputs are expected to use `public`, and beta/tag gray behavior is verified through the current gray model. Removed pre-3.0 compatibility migration paths, including empty-tenant storage migration and legacy `config_info_beta` / `config_info_tag` old-table migration, are not counted as missing OpenAPI IT coverage. ## Coverage Documents | API surface | Scenario document | Test package | | --- | --- | --- | | Client OpenAPI | [CLIENT_API_TEST_SCENARIOS.md](CLIENT_API_TEST_SCENARIOS.md) | `src/test/java/com/alibaba/nacos/test/openapi/client` | | Admin API | [ADMIN_API_TEST_SCENARIOS.md](ADMIN_API_TEST_SCENARIOS.md) | `src/test/java/com/alibaba/nacos/test/adminapi` | | Console API | [CONSOLE_API_TEST_SCENARIOS.md](CONSOLE_API_TEST_SCENARIOS.md) | `src/test/java/com/alibaba/nacos/test/consoleapi` |