Standardize component and integration test plan filenames

.cursor/commands/review-component-tests-standards.md

@@ -19,7 +19,7 @@ Before reviewing, **ALWAYS** read the latest version of the component testing do
 1. Read `docs/component-tests.md` for the overall framework architecture and features
 2. Review the common component test code in `swatch-test-framework/` to understand the framework implementation, utilities, and available tools
 3. Check the specific service's `ct/README.md` for deployment and execution instructions
-4. **Check if the service has a `TEST_PLAN.md`** file in the service root directory (e.g., `swatch-contracts/TEST_PLAN.md`). If it exists:
+4. **Check if the service has a `COMPONENT_TEST_PLAN.md`** file in the service root directory (e.g., `swatch-contracts/COMPONENT_TEST_PLAN.md`). If it exists:
    - Each test annotated with `@TestPlanName("test-id")` must correspond to a test case defined in this document
    - Verify that the test implementation matches the test case description, objectives, and expected behavior
    - Ensure the test covers all the requirements specified in the test plan
@@ -586,8 +586,8 @@ When reviewing a component test:
 - [ ] Is the test method name descriptive?
 - [ ] Do test and helper method names not exceed 65 characters?
 - [ ] Is `@TestPlanName` annotation present (if applicable)?
-- [ ] If `@TestPlanName` is used, does the service have a `TEST_PLAN.md` file?
-- [ ] If `TEST_PLAN.md` exists, does the test implementation match the test case definition?
+- [ ] If `@TestPlanName` is used, does the service have a `COMPONENT_TEST_PLAN.md` file?
+- [ ] If `COMPONENT_TEST_PLAN.md` exists, does the test implementation match the test case definition?
 - [ ] Does the test cover all requirements specified in the corresponding test plan case?
 
 ### 2. Code Quality Review
@@ -706,7 +706,7 @@ assertEquals(2, contracts.size(), "Should have exactly two contracts");
 
 - **Always read** `docs/component-tests.md` before reviewing
 - **Always review** `swatch-test-framework/` code to understand available utilities and patterns
-- **Always check** for `TEST_PLAN.md` in the service directory and validate `@TestPlanName` correspondence
+- **Always check** for `COMPONENT_TEST_PLAN.md` in the service directory and validate `@TestPlanName` correspondence
 - **Always verify** test class names match test plan naming convention (remove `-TCXXX` suffix, add `ComponentTest`)
 - **Always verify** service facade methods match OpenAPI `operationId` names exactly
 - **Always verify** methods are ordered according to Java conventions (static → public → protected → private) and helper methods follow given-when-then order

docs/TEST-COVERAGE.md

@@ -6,13 +6,13 @@ Central index of all test plans across SWATCH services. Each service has compone
 
 | Service | Component Test Plan | Integration Test Plan |
 |---|---|---|
-| swatch-tally | [SWATCH-TALLY-COMPONENT-TEST-PLAN.md](../swatch-tally/SWATCH-TALLY-COMPONENT-TEST-PLAN.md) | [SWATCH-TALLY-INTEGRATION-TEST-PLAN.md](../swatch-tally/SWATCH-TALLY-INTEGRATION-TEST-PLAN.md) |
-| swatch-contracts | [SWATCH-CONTRACTS-COMPONENT-TEST-PLAN.md](../swatch-contracts/SWATCH-CONTRACTS-COMPONENT-TEST-PLAN.md) | [SWATCH-CONTRACTS-INTEGRATION-TEST-PLAN.md](../swatch-contracts/SWATCH-CONTRACTS-INTEGRATION-TEST-PLAN.md) |
-| swatch-billable-usage | [TEST_PLAN.md](../swatch-billable-usage/TEST_PLAN.md) | TBD |
-| swatch-metrics-hbi | [TEST_PLAN.md](../swatch-metrics-hbi/TEST_PLAN.md) | TBD |
-| swatch-metrics | [TEST_PLAN.md](../swatch-metrics/ct/TEST_PLAN.md) | TBD |
-| swatch-producer-aws | [TEST_PLAN.md](../swatch-producer-aws/TEST_PLAN.md) | TBD |
-| swatch-utilization | [TEST_PLAN.md](../swatch-utilization/TEST_PLAN.md) | TBD |
+| swatch-tally | [COMPONENT_TEST_PLAN.md](../swatch-tally/COMPONENT_TEST_PLAN.md) | [INTEGRATION_TEST_PLAN.md](../swatch-tally/INTEGRATION_TEST_PLAN.md) |
+| swatch-contracts | [COMPONENT_TEST_PLAN.md](../swatch-contracts/COMPONENT_TEST_PLAN.md) | [INTEGRATION_TEST_PLAN.md](../swatch-contracts/INTEGRATION_TEST_PLAN.md) |
+| swatch-billable-usage | [COMPONENT_TEST_PLAN.md](../swatch-billable-usage/COMPONENT_TEST_PLAN.md) | TBD |
+| swatch-metrics-hbi | [COMPONENT_TEST_PLAN.md](../swatch-metrics-hbi/COMPONENT_TEST_PLAN.md) | TBD |
+| swatch-metrics | [COMPONENT_TEST_PLAN.md](../swatch-metrics/COMPONENT_TEST_PLAN.md) | TBD |
+| swatch-producer-aws | [COMPONENT_TEST_PLAN.md](../swatch-producer-aws/COMPONENT_TEST_PLAN.md) | TBD |
+| swatch-utilization | [COMPONENT_TEST_PLAN.md](../swatch-utilization/COMPONENT_TEST_PLAN.md) | TBD |
 
 ## Cross-Service Integration Plans
 

swatch-billable-usage/TEST_PLAN.md → swatch-billable-usage/COMPONENT_TEST_PLAN.md

@@ -22,7 +22,7 @@ This document defines the **component-level test plan** for `swatch-billable-usa
 - Unit tests (covered in service unit test suites; not tracked in this plan)
 - End-to-end marketplace API submission (covered by `swatch-producer-aws`, `swatch-producer-azure`, and IQE integration tests)
 - `swatch-tally` tally computation logic
-- `swatch-contracts` contract creation and sync logic (covered by `swatch-contracts/TEST_PLAN.md`)
+- `swatch-contracts` contract creation and sync logic (covered by `swatch-contracts/COMPONENT_TEST_PLAN.md`)
 - Stage/prod long-run heartbeat tests
 - Performance, load, and chaos testing
 

swatch-billable-usage/ct/README.md

@@ -42,4 +42,4 @@ The key difference is the addition of the `-Dswatch.component-tests.global.targe
 
 ## Test plan
 
-Component test cases (TC IDs, setup, and expected results) are documented in [`../TEST_PLAN.md`](../TEST_PLAN.md).
+Component test cases (TC IDs, setup, and expected results) are documented in [`../COMPONENT_TEST_PLAN.md`](../COMPONENT_TEST_PLAN.md).

swatch-billable-usage/ct/java/tests/ContractAdjustmentComponentTest.java

@@ -43,7 +43,8 @@
 /**
  * Component tests for ROSA contract-adjustment remittance (SWATCH-4615).
  *
- * <p>See {@code swatch-billable-usage/TEST_PLAN.md} — Contract Adjustment Remittance (TC001–TC002).
+ * <p>See {@code swatch-billable-usage/COMPONENT_TEST_PLAN.md} — Contract Adjustment Remittance
+ * (TC001–TC002).
  *
  * <p>Contract coverage is stubbed via {@link api.ContractsWiremockService}; usage arrives on Kafka
  * {@code TALLY}; assertions use {@link api.BillableUsageSwatchService#getRemittances}. Expected

swatch-contracts/SWATCH-CONTRACTS-INTEGRATION-TEST-PLAN.md → swatch-contracts/INTEGRATION_TEST_PLAN.md

@@ -1,6 +1,6 @@
 # Integration Test Plan for swatch-contracts
 
-Component-level testing is covered in [SWATCH-CONTRACTS-COMPONENT-TEST-PLAN.md](SWATCH-CONTRACTS-COMPONENT-TEST-PLAN.md). This document covers integration testing that exercises swatch-contracts against real downstream services in a deployed environment (stage or ephemeral).
+Component-level testing is covered in [COMPONENT_TEST_PLAN.md](COMPONENT_TEST_PLAN.md). This document covers integration testing that exercises swatch-contracts against real downstream services in a deployed environment (stage or ephemeral).
 
 Integration tests live in the IQE plugin: [iqe-rhsm-subscriptions-plugin](https://gitlab.cee.redhat.com/insights-qe/iqe-rhsm-subscriptions-plugin/-/tree/master/iqe_rhsm_subscriptions/tests/integration/swatch_contracts?ref_type=heads)
 

swatch-tally/SWATCH-TALLY-INTEGRATION-TEST-PLAN.md → swatch-tally/INTEGRATION_TEST_PLAN.md

@@ -1,6 +1,6 @@
 # Integration Test Plan for swatch-tally
 
-Component-level testing is covered in [SWATCH-TALLY-COMPONENT-TEST-PLAN.md](SWATCH-TALLY-COMPONENT-TEST-PLAN.md). This document covers integration testing that exercises swatch-tally against real downstream services in a deployed environment (stage or ephemeral).
+Component-level testing is covered in [COMPONENT_TEST_PLAN.md](COMPONENT_TEST_PLAN.md). This document covers integration testing that exercises swatch-tally against real downstream services in a deployed environment (stage or ephemeral).
 
 Integration tests live in the IQE plugin: [iqe-rhsm-subscriptions-plugin](https://gitlab.cee.redhat.com/insights-qe/iqe-rhsm-subscriptions-plugin/-/tree/master/iqe_rhsm_subscriptions/tests/integration/swatch_tally?ref_type=heads)