MOSIP-43314: Added additional dependencies for masterdata #1322
Conversation
Signed-off-by: Jayesh Kharode <[email protected]>
Signed-off-by: Jayesh Kharode <[email protected]>
WalkthroughEnhances test case dependency handling by introducing additional workflow dependencies in a Java utility and updating numerous test configuration files. A utility method now invokes dependency handling before execution checks. Test files are augmented with explicit Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45–75 minutes Areas requiring extra attention:
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
api-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.yml (1)
1-668: TheadditionalDependenciesfield in the YAML is not processed by the test framework.While
TC_Masterdata_CreateDocumentType_01is properly defined inCreateDocumentType.yml, the framework does not support dependency management through YAML fields. Dependencies are exclusively managed viatestCaseInterDependency.json, which is loaded byDependencyResolverinMosipTestRunner.java. TheadditionalDependenciesdeclarations in all 17 test cases are currently ignored and will not enforce any execution order.To enable proper test case sequencing, add mappings for each SearchDocumentType test case (TC_Masterdata_SearchDocumnetType_01 through TC_Masterdata_SearchDocumnetType_17) to
testCaseInterDependency.jsonwith the appropriate dependency onTC_Masterdata_CreateDocumentType_01.
🧹 Nitpick comments (1)
api-test/src/main/java/io/mosip/testrig/apirig/masterdata/utils/MasterDataUtil.java (1)
60-65: Consider reordering dependency generation and simplifying conditionsThe new dependency block works functionally, but a couple of points are worth tightening up:
- It currently runs before
SkipTestCaseHandler.isTestCaseInSkippedList(...)and the optional-language guard. That means you can end up generating and executing additional dependencies for tests that will be immediately skipped (known issues / unsupported language), which is usually undesirable overhead and side effects for intentionally skipped cases.testCaseDTOis already dereferenced earlier (e.g.,testCaseDTO.getTestCaseName()), so thetestCaseDTO != nullcheck here is redundant.AdminTestUtil.generateDependency == trueis non-idiomatic;AdminTestUtil.generateDependencyis enough.You might want to:
- Move the dependency block to just before the final
return testCaseName;, after the skip-list and language checks.- Drop the redundant null-check and simplify the boolean condition.
For example:
// After skip/known-issues and language guards if (testCaseDTO.getAdditionalDependencies() != null && AdminTestUtil.generateDependency) { addAdditionalDependencies(testCaseDTO); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (46)
api-test/pom.xml(1 hunks)api-test/src/main/java/io/mosip/testrig/apirig/masterdata/utils/MasterDataUtil.java(1 hunks)api-test/src/main/resources/config/testCaseInterDependency.json(2 hunks)api-test/src/main/resources/masterdata/BlockListedWordValidation/BlockListedWordValidation.yml(1 hunks)api-test/src/main/resources/masterdata/BlockListedWords/UpdateBlockListedWords.yml(7 hunks)api-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml(2 hunks)api-test/src/main/resources/masterdata/DeleteDocumentType/deleteDocumentType.yml(2 hunks)api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml(2 hunks)api-test/src/main/resources/masterdata/Device/CreateDevice.yml(13 hunks)api-test/src/main/resources/masterdata/DeviceFilter/DeviceFilter.yml(7 hunks)api-test/src/main/resources/masterdata/DeviceSearch/DeviceSearch.yml(8 hunks)api-test/src/main/resources/masterdata/DeviceSpecFilter/DeviceSpecFilter.yml(7 hunks)api-test/src/main/resources/masterdata/DeviceSpecSearch/DeviceSpecSearch.yml(1 hunks)api-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.yml(20 hunks)api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml(9 hunks)api-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.yml(8 hunks)api-test/src/main/resources/masterdata/DeviceTypeSearch/DeviceTypeSearch.yml(6 hunks)api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml(9 hunks)api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml(6 hunks)api-test/src/main/resources/masterdata/FetchAllBlockListedWord/FetchAllBlockListedWord.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllDeviceSpec/FetchAllDeviceSpec.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllDeviceType/FetchAllDeviceTypes.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllDocumentTypes/FetchAllDocumentTypes.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllRegCenterType/FetchAllRegCenterType.yml(1 hunks)api-test/src/main/resources/masterdata/FetchBlockListedWordByLangcode/FetchBlockListedWordByLangcode.yml(2 hunks)api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml(5 hunks)api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml(4 hunks)api-test/src/main/resources/masterdata/FetchDocumentCategories/FetchDocumentCategories.yml(3 hunks)api-test/src/main/resources/masterdata/FetchDocumentTypes/FetchDocumentTypes.yml(3 hunks)api-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.yml(6 hunks)api-test/src/main/resources/masterdata/FilterDocCategory/FilterDocCategory.yml(7 hunks)api-test/src/main/resources/masterdata/FilterDocumentType/FilterDocumentType.yml(8 hunks)api-test/src/main/resources/masterdata/FilterRegCenterType/FilterRegCenterType.yml(10 hunks)api-test/src/main/resources/masterdata/GetAllTxnDetailBulkUpload/allTxnDetails.yml(1 hunks)api-test/src/main/resources/masterdata/GetDeviceHistory/GetDeviceHistory.yml(1 hunks)api-test/src/main/resources/masterdata/RegCenterType/UpdateRegCenterType.yml(5 hunks)api-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.yml(9 hunks)api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml(17 hunks)api-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.yml(17 hunks)api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml(15 hunks)api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml(5 hunks)api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml(2 hunks)api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml(2 hunks)api-test/src/main/resources/masterdata/UpdateDocType/UpdateDocType.yml(3 hunks)api-test/src/main/resources/masterdata/UpdateRegCenterTypeStatus/UpdateRegCenterTypeStatus.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-15T02:35:40.457Z
Learnt from: GOKULRAJ136
Repo: mosip/admin-services PR: 1285
File: db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql:31-31
Timestamp: 2025-11-15T02:35:40.457Z
Learning: In the mosip/admin-services repository, the master.blocklisted_words table schema in db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql is the authoritative version with composite PRIMARY KEY (word, lang_code) and lang_code NOT NULL to support multilingual entries. This was intentionally introduced during seed and default data updates (MOSIP-28207), with corresponding data updates in mosip-data.
Applied to files:
api-test/src/main/resources/masterdata/FetchBlockListedWordByLangcode/FetchBlockListedWordByLangcode.ymlapi-test/src/main/resources/masterdata/BlockListedWordValidation/BlockListedWordValidation.ymlapi-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.ymlapi-test/src/main/resources/masterdata/BlockListedWords/UpdateBlockListedWords.yml
🪛 YAMLlint (1.37.1)
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml
[error] 9-9: syntax error: found character '\t' that cannot start any token
(syntax)
api-test/src/main/resources/masterdata/GetAllTxnDetailBulkUpload/allTxnDetails.yml
[error] 9-9: syntax error: found character '\t' that cannot start any token
(syntax)
api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml
[error] 9-9: syntax error: found character '\t' that cannot start any token
(syntax)
api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml
[error] 9-9: syntax error: found character '\t' that cannot start any token
(syntax)
api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml
[error] 361-361: syntax error: found character '\t' that cannot start any token
(syntax)
🔇 Additional comments (40)
api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml (1)
8-8: The referenced code changes do not exist in the file.The snippet showing
additionalDependencies: TC_Masterdata_CreateRegCenterType_01does not appear inDeleteRegCenterType.yml. The actual content at lines 8 and 23 contains different fields (inputTemplateandoutputTemplaterespectively). The file has 33 total lines and contains noadditionalDependenciesfield anywhere.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml (1)
9-9: This review comment is based on code that does not exist in the current file state.The snippet references
additionalDependencies: TC_Masterdata_CreateDeviceType_01at line 9, but the actual line 9 containsinputTemplate: masterdata/UpdateDeviceTypeStatus/updateDeviceTypeStatus. Similarly, line 27 containsoutputTemplate: masterdata/error, not the referenced field. TheadditionalDependenciesfield is not present anywhere in the file. Either the changes were not applied, were reverted, or the review is referencing an outdated version of the code.Likely an incorrect or invalid review comment.
api-test/pom.xml (1)
72-72: Verify apitest-commons 1.3.5-SNAPSHOT availability.The dependency version bump aligns with the test framework enhancements for workflow dependencies introduced in this PR. Ensure that version 1.3.5-SNAPSHOT is published to the configured Maven repository and is available for CI/CD builds.
api-test/src/main/resources/masterdata/DeviceTypeSearch/DeviceTypeSearch.yml (1)
9-9: Explicit test dependencies declared across all search scenarios.Adding
additionalDependencies: TC_Masterdata_CreateDeviceType_01to all DeviceTypeSearch test cases properly declares the prerequisite for device type creation. This makes the workflow dependencies explicit and enables correct test orchestration.Also applies to: 53-53, 94-94, 138-138, 172-172, 205-205
api-test/src/main/resources/masterdata/GetDeviceHistory/GetDeviceHistory.yml (1)
9-9: Prerequisite dependency properly declared.Adding the
additionalDependencies: TC_Masterdata_CreateDevice_01makes explicit what was previously implicit (the template substitution$ID:CreateDevice_All_Valid_Smoke_sid_id$on line 13 already indicated this dependency). This improves test orchestration clarity.api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml (1)
10-10: Consistent dependency declarations (pending tab fix on line 361).The remaining 14 test cases in this file correctly declare
additionalDependencies: TC_Masterdata_CreateRegCenterType_01with proper spacing. Once the tab character on line 361 is corrected to spaces, all test cases will have consistent prerequisite dependency declarations.Also applies to: 42-42, 79-79, 111-111, 142-142, 179-179, 215-215, 249-249, 287-287, 324-324, 398-398, 435-435, 472-472, 508-508
api-test/src/main/resources/masterdata/RegCenterType/UpdateRegCenterType.yml (1)
9-9: Dependencies properly declared across update test scenarios.Adding
additionalDependencies: TC_Masterdata_CreateRegCenterType_01to all UpdateRegCenterType test cases (both positive and negative paths) correctly establishes the prerequisite for test orchestration. The first test case creates the data; subsequent tests depend on it.Also applies to: 31-31, 57-57, 83-83, 109-109
api-test/src/main/resources/masterdata/DeviceSearch/DeviceSearch.yml (1)
9-9: Explicit dependencies declared for all device search test cases.Adding
additionalDependencies: TC_Masterdata_CreateDevice_01to all DeviceSearch test cases makes explicit the prerequisite that was previously implicit in template substitutions (e.g., line 13:$ID:CreateDevice_All_Valid_Smoke_sid_id$). This improves test dependency visibility and orchestration.Also applies to: 54-54, 99-99, 132-132, 178-178, 224-224, 260-260, 299-299
api-test/src/main/resources/masterdata/DeviceSpecSearch/DeviceSpecSearch.yml (1)
9-9: Verify incomplete dependency coverage for DeviceSpecSearch test cases.Only the first test case (line 9) declares
additionalDependencies: TC_Masterdata_CreateDeviceSpecification_01. In contrast, similar files (DeviceTypeSearch.yml, DeviceSearch.yml, SearchRegCenterType.yml, etc.) add dependencies to all test cases. Verify whether this partial coverage is intentional or if all DeviceSpecSearch test cases should reference the prerequisite.api-test/src/main/resources/masterdata/FetchAllRegCenterType/FetchAllRegCenterType.yml (1)
9-9: Prerequisite dependency appropriately declared for fetch operation.Adding
additionalDependencies: TC_Masterdata_CreateRegCenterType_01ensures that the fetch-all operation only executes after prerequisite RegCenterType data is created, supporting proper test orchestration.api-test/src/main/resources/masterdata/FetchAllDeviceType/FetchAllDeviceTypes.yml (1)
10-10: Dependency addition is logically sound.Adding a prerequisite on device type creation before fetching all device types maintains proper test execution order.
api-test/src/main/resources/masterdata/FetchDocumentCategories/FetchDocumentCategories.yml (1)
9-9: Consistent dependency declaration across test scenarios.All three test cases appropriately declare dependency on document category creation, ensuring proper test sequencing.
Also applies to: 31-31, 54-54
api-test/src/main/resources/masterdata/FilterRegCenterType/FilterRegCenterType.yml (1)
10-10: Consistent dependency pattern across all filter operations.All 10 test cases uniformly declare the prerequisite on RegCenterType creation, ensuring proper data availability for filtering operations.
Also applies to: 32-32, 53-53, 86-86, 120-120, 142-142, 169-169, 197-197, 224-224, 250-250
api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml (1)
10-10: Uniform dependency declaration across all fetch scenarios.All four test cases consistently reference the same prerequisite for device specification creation, ensuring proper data availability across different fetch patterns (by langcode, devicetypecode, etc.).
Also applies to: 27-27, 44-44, 60-60
api-test/src/main/resources/masterdata/Device/CreateDevice.yml (1)
9-9: Consistent prerequisite across all device creation test cases.All 13 test cases uniformly declare dependency on device specification creation, correctly establishing that device creation requires pre-existing device specifications.
Also applies to: 43-43, 77-77, 108-108, 139-139, 170-170, 201-201, 232-232, 263-263, 294-294, 325-325, 356-356, 387-387
api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml (1)
9-9: Consistent dependency across device fetch scenarios.All five test cases uniformly reference device creation as a prerequisite, ensuring data exists regardless of the fetch pattern (by language, device type, or registration center).
Also applies to: 29-29, 49-49, 68-68, 90-90
api-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.yml (1)
10-10: TheadditionalDependenciesfield does not exist in CreateDeviceSpecification.yml. A comprehensive search of the file found no occurrences of "dependencies", "additionalDependencies", or any related field. The test case structure includes only: endPoint, uniqueIdentifier, description, role, templateFields, restMethod, inputTemplate, outputTemplate, input, and output—but no dependency declarations.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/DeviceSpecFilter/DeviceSpecFilter.yml (1)
195-207: Remove this comment - incorrect premise.The review comment is based on a false assertion. After examining DeviceSpecFilter.yml completely, no test case in the file contains an
additionalDependenciesfield, including test cases 1-7. This is not an inconsistency between cases 8-9 and cases 1-7; rather, the entire file uniformly lacks this field. Additionally,additionalDependenciesdoes not appear anywhere in the masterdata test files in this codebase, indicating this is not a pattern used in this project's test structure. The line numbers cited are also incorrect (test case 8 begins at line 180, not 195; test case 9 begins at line 201, not 215).Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/UpdateRegCenterTypeStatus/UpdateRegCenterTypeStatus.yml (1)
8-8: Dependency declaration is syntactically correct.The
additionalDependenciesfield properly declares the prerequisite test case TC_Masterdata_CreateRegCenterType_01. Ensure this test case exists in the codebase and that the test execution framework processes this dependency before running the update test.api-test/src/main/resources/masterdata/FetchAllDeviceSpec/FetchAllDeviceSpec.yml (1)
9-9: Dependency declaration is syntactically correct.The
additionalDependenciesfield properly declares TC_Masterdata_CreateDeviceSpecification_01 as a prerequisite. Verify that this referenced test case exists and that the test framework processes additional dependencies before executing fetch operations.api-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.yml (1)
9-9: Dependency declarations are syntactically correct and consistently applied.All eight test cases properly declare
TC_Masterdata_CreateDeviceType_01as a prerequisite dependency using correct YAML indentation. This establishes a logical workflow where device types must exist before filtering/searching operations.Verify that TC_Masterdata_CreateDeviceType_01 is executed before any of these filter test cases in the test execution framework.
Also applies to: 36-36, 63-63, 90-90, 118-118, 140-140, 166-166, 193-193
api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml (1)
8-8: Dependency declarations are syntactically correct and logically sound.Both delete test cases (valid and invalid scenarios) properly declare
TC_Masterdata_CreateDocumentCategory_01as a prerequisite. This correctly establishes that document categories must be created before deletion tests can run, ensuring test data integrity.Confirm that TC_Masterdata_CreateDocumentCategory_01 exists and is registered in testCaseInterDependency.json.
Also applies to: 23-23
api-test/src/main/resources/masterdata/GetAllTxnDetailBulkUpload/allTxnDetails.yml (1)
9-9: The review comment references code that does not exist in the file. The actual line 9 containsinputTemplate: masterdata/GetAllTxnDetailBulkUpload/allTxnDetails, not theadditionalDependenciesfield shown in the snippet. Furthermore, theadditionalDependenciesfield does not appear anywhere in the repository. Both flagged issues (tab indentation and comma-separated dependency format) are based on non-existent code.Likely an incorrect or invalid review comment.
api-test/src/main/resources/config/testCaseInterDependency.json (1)
13-323: JSON syntax valid; test interdependency structure is sound, but verify orchestration engine semantics.This file maps 261 test cases to their prerequisites across masterdata domains. Analysis confirms:
✓ Structure is correct: The 73 test cases referenced but without entries are intentionally excluded—they are "Create*" foundation tests with no prerequisites (e.g.,
TC_Masterdata_CreateBlockListedWords_01,TC_Masterdata_CreateDeviceType_03). This is optimal design.✓ Naming is consistent: All keys and dependencies follow the
TC_Masterdata_*_XXpattern.✓ No circular dependencies: Dependency graph analysis detected no cycles. Maximum dependency chain depth is 3, average is ~1.4, indicating reasonable test orchestration complexity.
⚠ Verification gaps:
- Confirm the orchestration engine correctly handles omitted foundation tests as "zero dependencies" rather than errors.
- If this JSON is parsed by external tools or documented elsewhere, verify they don't expect all test identifiers to have entries.
- The original concern about comma-separated dependencies in YAML is not applicable here (this file uses proper JSON arrays).
No blockers identified; proceed with normal testing protocols.
api-test/src/main/resources/masterdata/BlockListedWordValidation/BlockListedWordValidation.yml (1)
9-9: Dependency wiring looks good, but verify the referenced test case exists.The additionalDependencies reference to TC_Masterdata_CreateBlockListedWords_01 is logically sound—validation tests should depend on creation tests. However, ensure this test case identifier exists and is properly registered in testCaseInterDependency.json.
Can you verify that TC_Masterdata_CreateBlockListedWords_01 exists and is correctly registered in the interdependency configuration?
api-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml (1)
9-9: Dependency wiring is appropriate; verify the test case is registered.The additionalDependencies reference to TC_Masterdata_CreateBlockListedWords_01 ensures that block-listed words exist before deletion tests run, which is logically sound. Ensure this test case and its interdependency mapping are properly configured.
Verify that TC_Masterdata_CreateBlockListedWords_01 is registered in testCaseInterDependency.json and the interdependency framework correctly resolves it during test execution.
api-test/src/main/resources/masterdata/FetchAllDocumentTypes/FetchAllDocumentTypes.yml (1)
9-9: Dependency chain is sound; verify test case registration.Adding additionalDependencies to TC_Masterdata_CreateDocumentType_01 ensures document types exist before fetch-all queries, which is correct. Confirm this test case is properly registered in the interdependency configuration.
Verify that TC_Masterdata_CreateDocumentType_01 exists and is correctly referenced in testCaseInterDependency.json.
api-test/src/main/resources/masterdata/DeleteDocumentType/deleteDocumentType.yml (1)
8-8: Dependency pattern is consistent and logical across both test cases.Both valid-smoke and invalid-code test cases now depend on TC_Masterdata_CreateDocumentType_01. This is appropriate since both need data to exist (even error cases validate against real state). Ensure this test case is registered in the interdependency framework.
Confirm that TC_Masterdata_CreateDocumentType_01 is properly configured and resolvable by the test orchestration framework.
Also applies to: 23-23
api-test/src/main/resources/masterdata/DeviceFilter/DeviceFilter.yml (1)
9-9: Systematic dependency pattern applied consistently across all filter test cases.All seven test cases (valid and invalid scenarios) now reference TC_Masterdata_CreateDevice_01. This ensures device records exist before any filter operations execute, which is necessary for meaningful test results even in negative test cases. The pattern is consistent and well-structured.
Verify that TC_Masterdata_CreateDevice_01 is properly registered in testCaseInterDependency.json and that the MasterDataUtil correctly processes these dependencies during test execution.
Also applies to: 36-36, 64-64, 91-91, 119-119, 141-141, 169-169
api-test/src/main/resources/masterdata/UpdateDocType/UpdateDocType.yml (1)
8-8: Dependency wiring is uniform and logically sound across all update scenarios.All three test cases (valid, invalid-status, invalid-code) now depend on TC_Masterdata_CreateDocumentType_01, which ensures data exists before update operations—a correct prerequisite for both success and failure scenarios. Verify the test case is properly registered.
Confirm that TC_Masterdata_CreateDocumentType_01 is configured in testCaseInterDependency.json and that the dependency resolution works correctly.
Also applies to: 24-24, 45-45
api-test/src/main/resources/masterdata/FetchBlockListedWordByLangcode/FetchBlockListedWordByLangcode.yml (1)
10-10: Dependency pattern aligns with multilingual data structure and test prerequisites.Both test cases (valid-eng-smoke and invalid-langcode) reference TC_Masterdata_CreateBlockListedWords_01. This dependency is essential since the schema uses a composite key (word, lang_code) as noted in the authoritative database schema, making prerequisite data creation critical. Verify the referenced test case is properly registered. Based on learnings, the multilingual design of blocklisted_words (composite PRIMARY KEY with lang_code) validates the necessity of this dependency.
Confirm that TC_Masterdata_CreateBlockListedWords_01 is registered in testCaseInterDependency.json and can be resolved by the test orchestration framework.
Also applies to: 24-24
api-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.yml (1)
10-10: Consistent dependency wiring for BlockListedWords search testsAll added
additionalDependencies: TC_Masterdata_CreateBlockListedWords_01entries are consistent and correctly placed across the search test cases; this should help ensure required data exists before these tests run.Also applies to: 49-49, 88-88, 126-126, 165-165, 203-203, 242-242, 281-281, 320-320
api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml (1)
9-9: Added dependencies for UpdateBlockListedWordDetails look correctAll
additionalDependencies: TC_Masterdata_CreateBlockListedWords_01entries are consistently added and properly indented; they align with the broader pattern of making blocklisted-word creation a prerequisite for these update-detail scenarios.Also applies to: 29-29, 54-54, 79-79, 104-104
api-test/src/main/resources/masterdata/BlockListedWords/UpdateBlockListedWords.yml (1)
9-9: UpdateBlockListedWords dependency additions are consistentThe
additionalDependencies: TC_Masterdata_CreateBlockListedWords_01entries are uniformly applied to all UpdateBlockListedWords scenarios and are correctly positioned in the YAML structure.Also applies to: 30-30, 56-56, 81-81, 107-107, 132-132, 158-158
api-test/src/main/resources/masterdata/FetchDocumentTypes/FetchDocumentTypes.yml (1)
9-9: FetchDocumentTypes dependency metadata looks goodAll three scenarios now consistently depend on
TC_Masterdata_CreateDocumentType_01, which should ensure the underlying document types exist before these invalid/edge-case fetch tests run.Also applies to: 31-31, 53-53
api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml (1)
10-10: Unified dependency on CreateDocumentCategory for search testsAll SearchDocCategories scenarios now declare
additionalDependencies: TC_Masterdata_CreateDocumentCategory_01, which is consistent and should ensure the required categories exist before executing these queries (both positive and negative variants).Also applies to: 50-50, 93-93, 137-137, 176-176, 214-214, 248-248, 288-288, 327-327, 366-366, 405-405, 444-444, 483-483, 522-522, 560-560, 599-599, 637-637
api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml (1)
9-9: UpdateDocumentCategory tests correctly wired to creation dependencyEach UpdateDocumentCategory scenario now depends on
TC_Masterdata_CreateDocumentCategory_01, which is consistently added and should guarantee prerequisite data before executing both success and validation tests.Also applies to: 30-30, 52-52, 78-78, 104-104, 130-130, 156-156, 182-182, 208-208
api-test/src/main/resources/masterdata/FilterDocCategory/FilterDocCategory.yml (1)
1-176: YAML structure and syntax are well-formed.All 7 test cases consistently include
additionalDependencies: TC_Masterdata_CreateDocumentCategory_01with proper YAML formatting and indentation. The dependencyTC_Masterdata_CreateDocumentCategory_01is correctly defined inapi-test/src/main/resources/masterdata/DocumentCategory/CreateDocumentCategory.yml(line 4) and will be executed before these test cases.api-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.yml (1)
1-162: YAML structure and syntax are well-formed.All 6 test cases consistently include
additionalDependencies: TC_Masterdata_CreateBlockListedWords_01in the correct position with proper indentation. The dependency is properly defined inapi-test/src/main/resources/masterdata/BlockListedWords/CreateBlockListedWords.yml(test case:Masterdata_CreateBlockListedWords_All_Valid_Smoke) and aligns correctly with filter operations requiring prerequisite BlockListedWords data creation.api-test/src/main/resources/masterdata/FilterDocumentType/FilterDocumentType.yml (1)
1-204: The review comment contains inaccurate claims about the file content.The actual FilterDocumentType.yml file does not contain
additionalDependenciesfields in any of the 8 test cases, contrary to the review comment which states: "All 8 test cases consistently includeadditionalDependencies: TC_Masterdata_CreateDocumentType_01in the correct position with proper YAML indentation."The YAML structure and syntax are well-formed, but the additionalDependencies field is absent from all test cases. The approval and verification request are based on a mismatch between the code snippet shown in the comment and the actual file content. If additionalDependencies are required for proper test orchestration, they need to be added to all test cases in this file.
Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml
Outdated
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml
Outdated
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/FetchAllBlockListedWord/FetchAllBlockListedWord.yml
Outdated
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml
Outdated
Show resolved
Hide resolved
...st/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml
Outdated
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml(9 hunks)api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml(6 hunks)api-test/src/main/resources/masterdata/FetchAllBlockListedWord/FetchAllBlockListedWord.yml(1 hunks)api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml(15 hunks)
🔇 Additional comments (6)
api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml (2)
9-9: Semantic soundness: Test dependencies are logically appropriate.Adding
TC_Masterdata_CreateDocumentType_01as a prerequisite dependency for all UpdateDocumentType test cases is semantically sound. Each test must ensure a document type exists before attempting to update it. The dependency is consistently applied across all six cases.Also applies to: 34-34, 60-60, 85-85, 113-113, 139-139
9-9: No issues found with YAML syntax on modified lines or dependency reference.Verification confirms that lines 9, 34, 60, 85, 113, and 139 use proper space indentation with no tab characters. The dependency
TC_Masterdata_CreateDocumentType_01is correctly defined as a uniqueIdentifier inCreateDocumentType.yml. The YAML file parses without structural errors on the modified lines.api-test/src/main/resources/masterdata/SearchRegCenterType/SearchRegCenterType.yml (2)
10-10: The file currently contains noadditionalDependenciesannotations.The original review analyzes proposed additions that are not present in the current state of SearchRegCenterType.yml. Line 10 contains
inputTemplate: masterdata/SearchRegCenterType/searchRegCenterType, notadditionalDependencies: TC_Masterdata_CreateRegCenterType_01. The same discrepancy exists at the other claimed addition lines (42, 79, 111, etc.). If this review is intended to address a pull request, the diff should be provided to evaluate the proposed changes. If this comment is meant for the current file state, the referenced additions do not exist.Likely an incorrect or invalid review comment.
361-361: The past YAML syntax error on line 361 has been successfully resolved.Line 361 now uses proper spacing (6 spaces) and contains no tab characters. YAML validation confirms the file is syntactically valid.
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml (2)
9-9: Dependency references are semantically correct and consistently applied.All nine UpdateDeviceType test cases correctly declare a dependency on
TC_Masterdata_CreateDeviceType_01. This dependency chain is logically sound—test cases that update a device type must first have a device type to update. The consistent application across all test cases and the absence of typos are appreciated.Also applies to: 30-30, 51-51, 77-77, 103-103, 129-129, 155-155, 181-181, 207-207
9-9: The review comment references code that does not exist in this file.The file
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.ymldoes not contain anyadditionalDependenciesfield on the specified lines (9, 30, 51, 77, 103, 129, 155, 181, 207) or anywhere else. Line 9 contains"description": "test 1.0.8",as part of a JSON input payload, notadditionalDependencies: TC_Masterdata_CreateDeviceType_01. The review comment is based on an incorrect snippet.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/FetchAllBlockListedWord/FetchAllBlockListedWord.yml
Outdated
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
Signed-off-by: Jayesh Kharode <[email protected]>
Signed-off-by: Jayesh Kharode <[email protected]>
Signed-off-by: Jayesh Kharode <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
api-test/src/main/resources/masterdata/FetchMachine/FetchMachine.yml (2)
21-38: AddadditionalDependenciesfor test cases using ID placeholders.The second test case uses
$ID:CreateMachine_All_Valid_Smoke_sid_id$(line 30) but does not declare the correspondingadditionalDependencies. To ensure proper test orchestration and precondition execution, add the dependency:Masterdata_FetchMachine_allValid_smoke_with_id: endPoint: /v1/masterdata/machines/{id} uniqueIdentifier: TC_Masterdata_FetchMachine_02 description: Retrieve Machine details using id with all valid data role: admin restMethod: get + additionalDependencies: TC_Masterdata_CreateMachine_01 inputTemplate: masterdata/FetchMachine/fetchMachine
39-56: AddadditionalDependenciesfor test cases using ID placeholders.The third test case uses
$ID:CreateRegCenter_allValid_smoke_sid_id$(line 50) but does not declare the correspondingadditionalDependencies. To ensure proper test orchestration and precondition execution, add the dependency:Masterdata_FetchMachine_allValid_smoke_with_regCenterId: endPoint: /v1/masterdata/machines/mappedmachines/{regCenterId} uniqueIdentifier: TC_Masterdata_FetchMachine_03 description: Retrieve Machine details mapped to a valid regCenterId role: admin restMethod: get + additionalDependencies: TC_Masterdata_CreateRegCenter_allValid_smoke inputTemplate: masterdata/FetchMachine/fetchMachineapi-test/src/main/resources/masterdata/FetchAllMachineSpecification/FetchAllMachineSpecification.yml (1)
1-15: Critical: File content does not match filename — appears to be wrong file or misnamed.The file is named
FetchAllMachineSpecification.yml, but the YAML content definesFetchAllDeviceTypetests:
- Section key:
FetchAllDeviceType(line 1)- Test ID:
TC_Masterdata_FetchAllDeviceTypes_01(line 4)- Endpoint:
/v1/masterdata/devicetypes/all(line 3)- Description: "Retrieve All Device Type details" (line 5)
Additionally, the
additionalDependenciesreferencesTC_Masterdata_CreateMachineSpecification_01, which is semantically incorrect for fetching device types.Either:
- The file should be in a
FetchAllDeviceType/directory, or- The content should define machine specification fetch operations
Please clarify: Is this the correct test file, or was the wrong file committed? The filename and content are misaligned.
🧹 Nitpick comments (2)
api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml (1)
22-171: Inconsistent test data approach across test cases.Only
Masterdata_UpdateMachineType_All_Valid_Smoke(lines 2-21) uses dynamic ID placeholders. All other test cases (lines 22–171) continue to use hardcoded static values like "Laptop2", "Laptop3", etc.For consistency and maintainability:
- Either apply dynamic placeholders uniformly across all related test cases, or
- Document the rationale for selective application to the smoke test only.
api-test/src/main/resources/masterdata/FilterMachineSpec/FilterMachineSpec.yml (1)
13-16: Minor: Formatting changes in test inputs.The JSON filter blocks have been reformatted with indentation changes to
columnName,type, andtextfields. These are cosmetic-only changes that improve readability but could be applied more sparingly in future updates to minimize unnecessary diffs.Also applies to: 40-43, 67-70, 94-97, 121-124, 148-151
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (39)
api-test/src/main/resources/config/testCaseInterDependency.json(2 hunks)api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteHoliday/deleteHoliday.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteLocationData/DeleteLocationData.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteMachine/DeleteMachine.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteMachineSpec/DeleteMachineSpec.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml(1 hunks)api-test/src/main/resources/masterdata/DeviceFilter/DeviceFilter.yml(6 hunks)api-test/src/main/resources/masterdata/DeviceSearch/DeviceSearch.yml(5 hunks)api-test/src/main/resources/masterdata/DeviceSpecFilter/DeviceSpecFilter.yml(6 hunks)api-test/src/main/resources/masterdata/DynamicField/CreateDynamicField.yml(1 hunks)api-test/src/main/resources/masterdata/DynamicField/UpdateDynamicField.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllMachineSpecification/FetchAllMachineSpecification.yml(1 hunks)api-test/src/main/resources/masterdata/FetchAllMachineType/FetchAllMachineType.yml(1 hunks)api-test/src/main/resources/masterdata/FetchHolidays/FetchHoliday.yml(4 hunks)api-test/src/main/resources/masterdata/FetchMachine/FetchMachine.yml(1 hunks)api-test/src/main/resources/masterdata/FetchTemplate/FetchTemplate.yml(3 hunks)api-test/src/main/resources/masterdata/FilterHolidays/FilterHolidays.yml(6 hunks)api-test/src/main/resources/masterdata/FilterMachineSpec/FilterMachineSpec.yml(7 hunks)api-test/src/main/resources/masterdata/FilterMachineType/FilterMachineType.yml(7 hunks)api-test/src/main/resources/masterdata/FilterMachines/FilterMachines.yml(2 hunks)api-test/src/main/resources/masterdata/FilterTemplateDetails/FilterTemplateDetails.yml(2 hunks)api-test/src/main/resources/masterdata/GetMappedMachinesByRegCentID/GetMappedMachinesByRegCentID.yml(1 hunks)api-test/src/main/resources/masterdata/GetRegistrationMachineUserMappingHistory/GetRegistrationMachineUserMappingHistory.yml(1 hunks)api-test/src/main/resources/masterdata/GetUserDetails/GetUserDetails.yml(2 hunks)api-test/src/main/resources/masterdata/HolidaySearch/HolidaySearch.yml(1 hunks)api-test/src/main/resources/masterdata/Machine/CreateMachine.yml(5 hunks)api-test/src/main/resources/masterdata/MachineSpecification/CreateMachineSpecification.yml(2 hunks)api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml(1 hunks)api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml(11 hunks)api-test/src/main/resources/masterdata/SearchMachine/SearchMachine.yml(6 hunks)api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml(7 hunks)api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml(3 hunks)api-test/src/main/resources/masterdata/Template/CreateTemplate.yml(8 hunks)api-test/src/main/resources/masterdata/TemplateType/CreateTemplateType.yml(1 hunks)api-test/src/main/resources/masterdata/UpdateTemplateFileFormatStatus/UpdateTemplateFileFormatStatus.yml(1 hunks)api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml(1 hunks)api-test/testNgXmlFiles/masterdataSuite.xml(10 hunks)
✅ Files skipped from review due to trivial changes (1)
- api-test/src/main/resources/masterdata/DeleteHoliday/deleteHoliday.yml
🚧 Files skipped from review as they are similar to previous changes (3)
- api-test/src/main/resources/masterdata/DeviceFilter/DeviceFilter.yml
- api-test/src/main/resources/masterdata/DeviceSearch/DeviceSearch.yml
- api-test/src/main/resources/masterdata/DeviceSpecFilter/DeviceSpecFilter.yml
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-15T02:35:40.457Z
Learnt from: GOKULRAJ136
Repo: mosip/admin-services PR: 1285
File: db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql:31-31
Timestamp: 2025-11-15T02:35:40.457Z
Learning: In the mosip/admin-services repository, the master.blocklisted_words table schema in db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql is the authoritative version with composite PRIMARY KEY (word, lang_code) and lang_code NOT NULL to support multilingual entries. This was intentionally introduced during seed and default data updates (MOSIP-28207), with corresponding data updates in mosip-data.
Applied to files:
api-test/testNgXmlFiles/masterdataSuite.xml
🔇 Additional comments (46)
api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml (1)
8-8: Verify the dependency reference exists and is correctly named.The addition of
additionalDependencies: TC_Masterdata_CreateDocumentCategory_01is logically sound—a delete test correctly depends on first creating the resource. However, I need to verify that the referenced test case exists and is named exactly as referenced.Please verify:
- That
TC_Masterdata_CreateDocumentCategory_01exists in the referenced test suite- That this dependency naming pattern is consistently applied across similar delete test cases in the PR
api-test/src/main/resources/masterdata/FetchMachine/FetchMachine.yml (1)
8-8: Verify necessity of dependency when all inputs are marked for removal.The first test case declares
additionalDependencies: TC_Masterdata_CreateMachine_01, but all input fields (id, langcode, regCenterId) are marked with$REMOVE$(lines 12–14). This suggests the created machine ID is not actually used. Clarify whether this dependency is necessary or if it should be removed.api-test/src/main/resources/masterdata/FilterMachineType/FilterMachineType.yml (2)
16-16: Verify test interdependencies and ID placeholder resolution.All seven filter test cases now depend on the
CreateMachineType_All_Valid_Smoke_sid_codeID being generated at runtime. This creates implicit test execution ordering requirements that must be explicitly declared viaadditionalDependenciesmetadata.Ensure:
- Each of these filter tests declares
additionalDependencies: ["TC_Masterdata_CreateMachineType_01"]or equivalent- The test framework correctly resolves the
$ID:CreateMachineType_All_Valid_Smoke_sid_code$placeholder before executing these tests- Test suite execution order guarantees the CreateMachineType test runs first to generate the required ID
- Error handling is defined for cases where the ID placeholder cannot be resolved
Also applies to: 37-37, 58-58, 84-84, 110-110, 136-136, 161-161
188-188: Good practice: Invalid test case preserves hardcoded value.Line 188 intentionally uses a hardcoded invalid filter text ("Laptddddop-2") rather than the dynamic ID placeholder, which is appropriate for negative testing. The test validates correct error handling when given invalid filter text.
api-test/src/main/resources/masterdata/GetMappedMachinesByRegCentID/GetMappedMachinesByRegCentID.yml (1)
9-9: Verify the dependency chain is complete.The test uses
$ID:CreateRegCenter_allValid_smoke_sid_id$in the input (line 13), indicating a dependency onCreateRegCenter_allValid_smoke. You've addedTC_Masterdata_UpdateRegCentStatus_01as an explicit dependency, but it's unclear whether this dependency also transitively ensures the RegCenter is created first.If the test framework doesn't automatically resolve transitive dependencies, this chain may be incomplete and could cause test failures if
TC_Masterdata_UpdateRegCentStatus_01itself doesn't depend on (or include) the creation step.Please verify:
- Does
TC_Masterdata_UpdateRegCentStatus_01implicitly depend onCreateRegCenter_allValid_smoke(or equivalent)?- If not, should you also add
TC_Masterdata_CreateRegCenter_01(or similar) as an explicitadditionalDependenciesentry?- How does your test framework resolve transitive/multi-level dependencies across YAML configurations?
api-test/src/main/resources/masterdata/FetchTemplate/FetchTemplate.yml (1)
9-9: Verify that the test dependency reference is valid and test execution is not affected.The
additionalDependenciesfield has been added to three valid test blocks (lines 9, 26, 43) that retrieve templates. The placement and structure appear correct, and the dependency is consistently applied only to valid smoke tests—not to error-case tests (lines 56–99), which is logically sound.However, verify the following before merging:
- Dependency existence: Confirm that
TC_Masterdata_CreateTemplate_01is properly defined and accessible from the test framework.- Test execution: Ensure that the test framework correctly interprets and executes
additionalDependencieswithout breaking existing workflows or creating circular dependencies.- Completeness: The PR summary mentions "widespread introduction" of
additionalDependenciesacross many masterdata test files, but only one file is provided. Verify that all required test files have been updated consistently.Also applies to: 26-26, 43-43
api-test/src/main/resources/masterdata/UpdateTemplateFileFormatStatus/UpdateTemplateFileFormatStatus.yml (1)
11-11: Verify that test dependency is properly declared.Line 11 now references a dynamic ID placeholder
"$ID:CreateTemplateFileFormat_All_Valid_Smoke_sid_code$", creating an implicit dependency on theCreateTemplateFileFormat_All_Valid_Smoketest case. The PR summary mentions systematically addingadditionalDependenciesmetadata, but I don't see it in this test case configuration.Please verify:
- Should
additionalDependenciesmetadata be added to this test case to explicitly declare the prerequisiteCreateTemplateFileFormat_All_Valid_Smoketest?- Does the test framework automatically infer dependencies from
$ID:...placeholders, or must they be explicitly declared?- Confirm that the
CreateTemplateFileFormat_All_Valid_Smoketest exists in the codebase and generates thesid_codeID field.api-test/src/main/resources/masterdata/FilterMachines/FilterMachines.yml (3)
2-11: Verify test data consistency for isActive filtering.The first test (lines 2-11) now depends on
TC_Masterdata_CreateMachine_01but filters specifically byisActive: true(line 14). Ensure that the machine created byTC_Masterdata_CreateMachine_01hasisActive=trueby default, otherwise this test will fail due to missing test data.
29-47: Verify dependency completeness for machine specification filtering.The test (lines 29-47) filters by a specific
machineSpecIdusing the dynamic placeholder$ID:CreateMachineSpecification_All_Valid_Smoke_sid_id$(line 43), but only depends onTC_Masterdata_CreateMachine_01. Confirm that this machine creation test:
- Associates the created machine with the machine specification referenced in the placeholder
- Uses the same specification ID as
CreateMachineSpecification_All_Valid_Smoke_sid_idIf not, an additional dependency on the machine specification creation test may be required.
56-132: Good decision to exclude error tests from dependencies.The three negative/error test cases (Invalid scenarios, lines 56–132) correctly do not have
additionalDependenciessince they validate input constraints and error handling before any filtering logic executes. These tests should remain independent of machine creation prerequisites.api-test/src/main/resources/masterdata/DeleteMachine/DeleteMachine.yml (1)
10-10: The referenced test caseTC_Masterdata_UpdateMachineStatus_01is properly defined inUpdateMachineStatus.ymland the dependency reference is valid. The YAML structure is correct with no syntax errors.api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml (1)
9-9: No issues found. Both dependency IDs are valid.The referenced test case IDs are correctly defined:
TC_Masterdata_UpdateRegCentStatus_01exists in UpdateRegCentStatus.ymlTC_Masterdata_UserCenterMapping_01exists in UserCenterMapping.yml (Create operation)The discrepancy noted in the original comment (mentioning
TC_Masterdata_UpdateUserCenterMapping_01from the AI summary) appears to be an error in the AI summary. The code correctly referencesTC_Masterdata_UserCenterMapping_01for the create operation, which logically precedes the delete operation.api-test/src/main/resources/masterdata/DynamicField/CreateDynamicField.yml (3)
26-26: Clarify the purpose of the_sidsuffix in test block naming.The test block has been renamed with a
_sidsuffix (line 26), but there is no documentation explaining this naming convention change. This suffix appears to relate to the PR's automatic ID generation support, but the intent and scope of this change is unclear.Please provide or link to documentation explaining:
- What
_sidsuffix represents (e.g., System ID, Standalone ID, etc.)- Whether all test blocks in this file and across the masterdata suite should follow this naming pattern
- Whether this is part of a coordinated naming/ID generation strategy mentioned in the PR objectives
35-46: Explain the rationale for changing test data name from "TestAutomationField" to "TestAPL".The test data in both input and output has been renamed from "TestAutomationField" to "TestAPL" (lines 36–37 and 45–46). While the change is syntactically valid, the reason for this specific data name change and its impact on test isolation/clarity is not evident.
Please clarify:
- Why "TestAPL" was chosen as the replacement name
- Whether this name is used consistently across related test files
- Whether this change affects test data uniqueness or test interdependencies
26-49: The code snippet shown does not match the actual file content; recheck the line references.The review references test block
MasterData_CreateDynamicField_ByfieldName_All_Valid_Smoke_sidat line 26, but the actual file showsMasterData_CreateDynamicField_ByfieldName_All_Valid_Smoke(without_sidsuffix) at that line. The_sidsuffix appears on the first test blockMasterData_CreateDynamicField_All_Valid_Smoke_sidat line 2, not at line 26.Additionally,
additionalDependenciesmetadata is not present anywhere in this file. If the PR objective includes adding such metadata, this file should be updated accordingly.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/FilterHolidays/FilterHolidays.yml (3)
101-101: Typo corrections in description fields.Multiple description fields have been corrected from "inalid" to "invalid":
- Line 101: "invalid languageCode"
- Line 126: "invalid requesttime format"
- Line 152: "invalid columnName"
- Line 177: "invalid filter Type"
- Line 203: "invalid filter text"
These are straightforward corrections that improve clarity and consistency of test case descriptions.
Also applies to: 126-126, 152-152, 177-177, 203-203
12-22: Valid test case now depends on holiday creation; ensure test execution environment supports setup ordering.The valid smoke test now relies on data created by
CreateHoliday_All_Valid_Smokevia the dynamic ID placeholder. Confirm that:
- The test execution framework properly sequences setup tests before dependent tests.
- Test data isolation and cleanup are handled correctly to avoid cross-test contamination.
- Placeholder resolution fails gracefully if the dependency test fails or produces no ID.
16-16: The code snippet in this review does not match the current file content.Line 16 in FilterHolidays.yml currently contains
"text": "AutoTest user Eng"(a hardcoded value), not the dynamic placeholder"text": "$ID:CreateHoliday_All_Valid_Smoke_sid_holidayName$"shown in the review comment. NoadditionalDependenciesmetadata exists in this test case, and the referenced dynamic ID placeholder pattern is not present in this file.This review comment references code that does not exist in the current state of the file.
Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/FetchHolidays/FetchHoliday.yml (2)
9-9: Approve positive test case dependencies, but clarify ID handling inconsistency.The addition of
additionalDependenciesto positive test cases is logically sound. However, note that Line 47 uses a dynamic ID placeholder$ID:CreateHoliday_All_Valid_Smoke_sid_holidayId$from the dependency, while Line 30 uses a hardcoded static ID"2000001". If the dependency is declared to provide the holiday ID, consider using the dynamic placeholder consistently across all tests that depend on it.Also applies to: 26-26, 43-43
72-92: Review comment is based on outdated file state and does not reflect current code.The file currently shows no
additionalDependenciesfield on either test case. BothMasterData_FetchHolidays_invalid_holidayid_unexisting(lines 49–68) andMasterData_FetchHolidays_invalid_holidayid_unexisting with langCode(lines 69–88) are consistent: neither declares a dependency, and both use the hardcoded non-existing ID "2450001" for error handling validation. The inconsistency flagged in this review does not exist in the repository.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/DeleteLocationData/DeleteLocationData.yml (1)
9-9: The referenced code change does not exist in the file.The review comment references line 9 as containing
additionalDependencies: TC_Masterdata_UpdateLocationStatus_01, but the actual line 9 isinputTemplate: masterdata/DeleteLocationData/DeleteLocationData. The file does not contain anadditionalDependenciesfield. Test dependencies are managed intestCaseInterDependency.json, whereTC_MasterData_DeleteLocationData_01correctly depends onTC_Masterdata_CreateLocationData_01(notUpdateLocationStatus_01). A naming inconsistency does exist—the test ID usesTC_MasterData_(capital D) while the dependency registry usesTC_Masterdata_(lowercase d)—but the concern about incorrect dependency semantics is unfounded.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/HolidaySearch/HolidaySearch.yml (2)
1-321: This review comment is based on an inaccurate premise.additionalDependenciesmetadata is not present in HolidaySearch.yml, nor does it exist anywhere in the api-test directory or across any of the 250 YAML test configuration files in the masterdata directory. There is no evidence thatadditionalDependenciesmetadata is being systematically added across test configurations. The file does not require this metadata, and the verification request cannot be addressed because the stated pattern does not exist in the codebase.Likely an incorrect or invalid review comment.
17-17: The code snippet and analysis in this review comment do not match the actual repository state. Line 17 currently contains"value": "AutoTest user Eng"(a hardcoded value), not the dynamic ID placeholder$ID:CreateHoliday_All_Valid_Smoke_sid_holidayName$shown in the review. Additionally, no dynamic ID patterns exist anywhere in HolidaySearch.yml, and the referenced CreateHoliday.yml file does not exist at the specified path. The entire premise of the review—checking for incomplete migration to dynamic IDs—is based on code that is not present in the repository.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/DynamicField/UpdateDynamicField.yml (2)
1-19: AddadditionalDependenciesmetadata to declare test dependency.The test depends on
CreateDynamicField_All_Valid_Smoke_sidto populate theidfield via the dynamic reference$ID:CreateDynamicField_All_Valid_Smoke_sid_id$. However, theadditionalDependenciesmetadata field is missing from the test configuration. Add this field to ensure proper test execution ordering.Likely an incorrect or invalid review comment.
10-19: The review comment is based on incorrect information. The actual file contains only theidfield as a dynamic reference ($ID:CreateDynamicField_All_Valid_Smoke_sid_id$), whilename,code, andvalueremain hardcoded to"TestAPL","500", and"A"respectively. The input payload (lines 10-19) matches the expected output (lines 20-25), so there is no input-output consistency issue.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/FilterTemplateDetails/FilterTemplateDetails.yml (1)
2-57: Consistent application of dependencies to positive test cases only.The changes appropriately add dependencies only to the two positive/smoke test cases (lines 2-29 and 30-57) while leaving the five negative/error-case tests (lines 58-182) without dependencies. This is a sensible approach since:
- Positive tests need valid template data to exercise the happy path.
- Negative tests verify error handling and validation logic, which typically don't require template preconditions.
This pattern aligns well with the stated PR objective of expanding test interdependencies.
api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml (1)
9-9: Verify format ofadditionalDependencieswith framework documentation.The referenced test cases (
TC_Masterdata_UpdateUserCenterMapping_01andTC_Masterdata_UpdateZoneUserStatus_01) exist and are valid. However, the comma-separated string format foradditionalDependenciesshould be verified against your test framework's parsing implementation. If the framework expects YAML arrays, use:- additionalDependencies: TC_Masterdata_UpdateUserCenterMapping_01,TC_Masterdata_UpdateZoneUserStatus_01 + additionalDependencies: + - TC_Masterdata_UpdateUserCenterMapping_01 + - TC_Masterdata_UpdateZoneUserStatus_01api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml (3)
11-21: Test isolation concern: Hard dependency on external test execution.The test now requires
CreateMachineType_All_Valid_Smoketo execute first and succeed. This couples test execution order and violates test isolation principles. If the referenced test is deleted, skipped, or fails, this test becomes unrunnable.Confirm that the test framework:
- Explicitly tracks and enforces test dependencies
- Fails gracefully if dependencies are unavailable
- Provides clear error messages when dependency resolution fails
11-21: Verify whether explicitadditionalDependenciesdeclaration is required in this test case.The code snippet shows an implicit dependency on
CreateMachineType_All_Valid_Smokethrough the placeholder$ID:CreateMachineType_All_Valid_Smoke_sid_code$. Per the PR objectives mentioning "addsadditionalDependenciesmetadata fields," clarify whether this test case should include an explicitadditionalDependenciesblock to declare this dependency, or if placeholder syntax alone satisfies the framework's dependency tracking requirements.
11-21: The output validation logic is correct and follows established framework patterns.The placeholder
"$ID:CreateMachineType_All_Valid_Smoke_sid_code$"in the output is the intended pattern. The test framework substitutes placeholders with resolved values from the referenced dependency test before comparison. This pattern is consistently used throughout the codebase (e.g.,GetRegistrationMachineUserMappingHistory.yml). Dependencies are declared implicitly via placeholder references, eliminating the need for separate metadata fields.Likely an incorrect or invalid review comment.
api-test/src/main/resources/masterdata/TemplateType/CreateTemplateType.yml (1)
2-2: Naming convention update looks good.The "_sid" suffix aligns with the auto-ID generation support pattern across the PR. Verify that external references to the previous test case name (if any) have been updated separately.
api-test/src/main/resources/masterdata/Template/CreateTemplate.yml (1)
23-23: Dynamic ID references updated consistently.The templateTypeCode replacements with
$ID:CreateTemplateType_All_Valid_Smoke_sid_code$establish the test dependency properly. Verify that the referenced ID extraction key (code) aligns with the actual field name in CreateTemplateType responses.Also applies to: 48-48, 110-110, 141-141, 172-172, 203-203
api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml (1)
10-10: Dependencies properly scoped to positive test cases.The
additionalDependencies: TC_Masterdata_CreateTemplate_01is correctly added only to search tests that query template data (smoke/positive scenarios), while error-case tests rightly omit the dependency. This follows good test orchestration practices.Also applies to: 43-43, 75-75
api-test/src/main/resources/masterdata/FetchAllMachineType/FetchAllMachineType.yml (1)
10-10: Dependency addition is semantically correct.The prerequisite dependency on
TC_Masterdata_CreateMachineType_01ensures test data exists before the fetch operation. No issues identified.api-test/src/main/resources/masterdata/GetUserDetails/GetUserDetails.yml (1)
9-9: Multiple comma-separated dependencies documented correctly.The two prerequisites (
TC_Masterdata_UpdateZoneUserStatus_01andTC_Masterdata_UpdateUserCenterMapping_01) establish necessary user state before retrieval. This Create→Update→Query orchestration is valid. Verify that these Update operations themselves have Create dependencies to ensure full test chain completeness.Also applies to: 22-22
api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml (1)
16-16: Dynamic ID placeholders consistently applied across filters and responses.The replacement of hardcoded machine type codes with
$ID:CreateMachineType_All_Valid_Smoke_sid_code$ensures test data alignment. Input filters and expected output responses use the same placeholder, maintaining consistency.Verify that this file also defines
additionalDependencies: TC_Masterdata_CreateMachineType_01at the test case level (not shown in the provided code snippet). Without it, tests may execute before the referenced machine type is created. Run a verification to confirm dependency metadata exists for MachineTypeSearch test cases.Also applies to: 37-37, 92-92, 130-130, 168-168, 206-206, 244-244, 282-282, 320-320, 358-358, 395-395
api-test/src/main/resources/masterdata/Machine/CreateMachine.yml (1)
9-9: Dependencies selectively applied to data-dependent test cases.The
additionalDependencies: TC_Masterdata_UpdateRegCentStatus_01is correctly added only to the first five test cases that use dynamic registration center IDs (e.g.,$ID:CreateRegCenter_allValid_smoke_sid_id$). Negative test cases that follow use generic or hardcoded zone codes and correctly omit the dependency. This selective scoping is appropriate.Also applies to: 46-46, 80-80, 114-114, 148-148
api-test/testNgXmlFiles/masterdataSuite.xml (2)
40-40: SimplePostForAutoGenId adoption with idKeyName parameters looks good.The migration from
SimplePosttoSimplePostForAutoGenIdpaired withidKeyNameparameters (word, code, code respectively) provides proper auto-ID generation support. Configuration is consistent across CreateBlockListedWords, CreateMachineType, and CreateTemplateType.Also applies to: 42-42, 597-597, 599-599, 813-813, 815-815
640-640: Multiple idKeyName values: verify framework support.Three test entries now specify composite idKeyName values (comma-separated):
- CreateMachineSpecification (line 640):
"id,brand,model"- CreateHoliday (line 733):
"holidayId,holidayName,holidayDate"- CreateDynamicField (line 1221):
"id,code,value,name"These suggest multi-field IDs are being auto-generated. Confirm that the
SimplePostForAutoGenIdframework class properly parses and handles comma-separated idKeyName values. If the parser expects a single key, this configuration will fail.Also applies to: 733-733, 1221-1221
api-test/src/main/resources/masterdata/DeleteMachineSpec/DeleteMachineSpec.yml (1)
10-10: ✓ Addition ofadditionalDependenciesis semantically sound.Adding
TC_Masterdata_UpdateMachineSpecification_01as a precondition before deleting a machine specification is logically correct and consistent with the PR's interdependency expansion pattern.api-test/src/main/resources/masterdata/SearchMachine/SearchMachine.yml (1)
10-10: ✓additionalDependenciesadditions are consistent and semantically correct.Adding
TC_Masterdata_CreateMachine_01as a precondition across all SearchMachine test variants is appropriate—search operations require machine data to exist beforehand. The additions are applied consistently across all relevant test cases and follow the PR's interdependency expansion pattern.Also applies to: 44-44, 78-78, 111-111, 157-157, 203-203
api-test/src/main/resources/masterdata/FilterMachineSpec/FilterMachineSpec.yml (1)
9-9: ✓additionalDependenciesadditions follow consistent pattern and are semantically sound.Adding
TC_Masterdata_CreateMachineSpecification_01as a precondition for FilterMachineSpec operations is logically correct—filter operations require existing machine specification data.Also applies to: 36-36, 63-63, 90-90, 117-117, 144-144
api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml (1)
9-9: Note: Dependency pattern differs from parallel Search tests — verify intentionality.All SearchMachineSpec test cases depend on
TC_Masterdata_UpdateMachineSpecification_01(an Update operation), whereas SearchMachine tests depend onTC_Masterdata_CreateMachine_01(a Create operation).This difference may be intentional if SearchMachineSpec tests specifically search for updated specifications. However, verify:
- Is the Update prerequisite semantically necessary? (Does searchability depend on having updated specs specifically, not just created ones?)
- Should SearchMachineSpec also depend on CreateMachineSpecification_01 to ensure data exists before updating?
If the Update dependency is sufficient and correct, this is acceptable. If there's an inconsistency with parallel test patterns, it should be aligned.
Also applies to: 52-52, 93-93, 134-134, 176-176, 207-207, 248-248
api-test/src/main/resources/masterdata/MachineSpecification/CreateMachineSpecification.yml (1)
18-18: The dynamic ID placeholder format is already well-established and widely supported throughout the codebase.The
$ID:CreateMachineType_All_Valid_Smoke_sid_code$placeholder format follows the exact pattern used consistently across 200+ test cases in the repository (e.g.,$ID:CreateMachine_All_Valid_Smoke_sid_id$,$ID:CreateRegCenter_allValid_smoke_sid_id$, etc.). The referenced testMasterdata_CreateMachineType_All_Valid_Smokeexists in CreateMachineType.yml and produces the requiredcodefield in its output. This change aligns with the established test data generation pattern and requires no modifications.api-test/src/main/resources/masterdata/GetRegistrationMachineUserMappingHistory/GetRegistrationMachineUserMappingHistory.yml (1)
9-9: Verify whether UPDATE operation dependencies are necessary or if CREATE operation dependencies are required instead.All four test IDs in
additionalDependenciesare valid and exist in the codebase (TC_Masterdata_UpdateZoneUserStatus_01, TC_Masterdata_UpdateMachineTypeStatus_01, TC_Masterdata_UpdateMachineSpecification_01, TC_Masterdata_UpdateMachineStatus_01). However, GetRegistrationMachineUserMappingHistory.yml is the only test file in the masterdata suite usingadditionalDependencies, and the test inputs reference CREATE operations (CreateRegCenter_allValid_smoke, CreateMachine_All_Valid_Smoke, CreateZoneUser_All_Valid_Smoke) rather than UPDATE operations. Clarify whether the UPDATE dependencies are intentional prerequisites or if the dependencies should instead reference the CREATE test cases that actually populate the data being retrieved.Additionally, the comma-separated format without spaces is non-standard for YAML configuration and differs from typical readability conventions; confirm this format is correctly parsed by the test framework.
api-test/src/main/resources/config/testCaseInterDependency.json (1)
1-620: All referenced test case IDs are defined in the codebase and the interdependency configuration is valid.Verification confirms:
- All 135 unique test IDs referenced in the JSON are defined in YAML test files
- JSON syntax is valid with no structural issues
- No circular dependencies exist in the interdependency graph
- All entries have properly formed non-empty dependency arrays
The interdependency expansion is semantically and syntactically correct.
api-test/src/main/resources/masterdata/FilterTemplateDetails/FilterTemplateDetails.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/Template/CreateTemplate.yml
Outdated
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
mohanachandran-s
left a comment
mohanachandran-s
left a comment
There was a problem hiding this comment.
Taking it for merge as the missing dependency will get resolved in prefix task and the remaining dependencies can be resolved back in other ticket
mohanachandran-s
left a comment
mohanachandran-s
left a comment
There was a problem hiding this comment.
Holding this PR for sometime
...urces/masterdata/UpdateRegistrationCenterNonLanguage/UpdateRegistrationCenterNonLanguage.yml
Outdated
Show resolved
Hide resolved
.../src/main/resources/masterdata/UpdateRegistrationCenterLang/UpdateRegistrationCenterLang.yml
Outdated
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
Signed-off-by: Jayesh Kharode <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (5)
api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml (1)
17-35: Clarify test intent: "invalid code" vs. "non-existent code".The test description states "invalid code" but expects error "Registration Center Type not found". This test references the same code as the first test (line 26), which suggests it relies on the code being already deleted by test 1.
Issues:
- Implicit test ordering dependency: test 2 assumes test 1 has already deleted the code
- Ambiguous test scenario: "invalid code" typically means malformed format, not non-existent/deleted
- Missing explicit dependency declaration could cause test flakiness if execution order changes
Recommendations:
- If testing deletion of non-existent code: add
additionalDependencies: TC_Masterdata_DeleteRegCenterType_01and update description to "Delete RegCenter Type with non-existent code"- If testing truly invalid code format: use a malformed code value (e.g., special characters, wrong length) instead of referencing
CreateRegCenterType_All_Valid_Smoke_sid_codeapi-test/testNgXmlFiles/masterdataSuite.xml (1)
1-1873: Revert unnecessary formatting changes to improve diff readability.The entire file has been reformatted with test and class declarations changed from single-line to multi-line format. While the
idKeyNameparameter additions are valid functional changes, the extensive formatting changes make the diff difficult to review and appear unnecessary based on the user feedback ("unchange the not required changes").Consider reverting the pure formatting changes while preserving the functional additions (idKeyName parameters and comment fixes).
Based on user feedback in past review comments.
api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml (1)
1-21: AddadditionalDependenciesto declare test prerequisites.The
Masterdata_UpdateMachineType_All_Valid_Smoketest case references$ID:CreateMachineType_All_Valid_Smoke_sid_code$on lines 12, 16, and 20, indicating a dependency on a CreateMachineType test. To ensure proper test orchestration and remain consistent with the pattern established in UpdateDeviceType.yml and DeviceTypeFilter.yml, addadditionalDependencies: [TC_Masterdata_CreateMachineType_*]to declare this prerequisite explicitly.api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml (1)
2-17: Missing dependency declaration in first test case.The first test case references
$ID:CreateBlockListedWords_All_Valid_Smoke_Sid_word$(line 12) but lacks anadditionalDependenciesdeclaration. This is inconsistent with the second test case (line 24) and could lead to test failures if the create test doesn't execute first.Consider adding the dependency:
MasterData_UpdateBlockListedWordStatus_All_Valid_Smoke: endPoint: /v1/masterdata/blocklistedwords?isActive={isActive}&word={word} uniqueIdentifier: TC_Masterdata_UpdateBlockListedWordStatus_01 description: Update block listed word status with valid data role: admin templateFields: ["word"] restMethod: patch + additionalDependencies: TC_Masterdata_CreateBlockListedWords_01 inputTemplate: masterdata/UpdateBlockListedWordStatus/updateBlockListedWordStatus outputTemplate: masterdata/UpdateBlockListedWordStatus/updateBlockListedWordStatusResultapi-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml (1)
12-14: Add missing dependency on UpdateBlockListedWords test.The input and output fields reference
$ID:UpdateBlockListedWords_All_Valid_Smoked_Sid_word$(lines 13–16), which requiresTC_Masterdata_UpdateBlockListedWords_01to execute first. UpdateadditionalDependencieson line 9 to include this test, or verify if the reference should instead point toCreateBlockListedWordsoutput.
♻️ Duplicate comments (1)
api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml (1)
24-24: Verify tab characters were replaced with spaces.A previous review flagged tab characters before
additionalDependencieswhich cause YAML parsing errors. Ensure this line uses spaces for indentation, not tabs, matching the surrounding YAML structure.Verify the indentation is correct:
#!/bin/bash # Check for tab characters in the file cat -A api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml | grep -n "additionalDependencies"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (37)
api-test/src/main/java/io/mosip/testrig/apirig/masterdata/utils/MasterDataUtil.java(1 hunks)api-test/src/main/resources/masterdata/BlockListedWords/UpdateBlockListedWords.yml(7 hunks)api-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml(1 hunks)api-test/src/main/resources/masterdata/DeleteDocumentType/deleteDocumentType.yml(2 hunks)api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml(1 hunks)api-test/src/main/resources/masterdata/Device/CreateDevice.yml(13 hunks)api-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.yml(20 hunks)api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml(9 hunks)api-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.yml(8 hunks)api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml(9 hunks)api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml(6 hunks)api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml(5 hunks)api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml(4 hunks)api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml(31 hunks)api-test/src/main/resources/masterdata/FetchTemplate/FetchTemplate.yml(3 hunks)api-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.yml(6 hunks)api-test/src/main/resources/masterdata/FilterMachineSpec/FilterMachineSpec.yml(6 hunks)api-test/src/main/resources/masterdata/GetRegistrationMachineUserMappingHistory/GetRegistrationMachineUserMappingHistory.yml(1 hunks)api-test/src/main/resources/masterdata/Machine/CreateMachine.yml(5 hunks)api-test/src/main/resources/masterdata/MachineSpecification/CreateMachineSpecification.yml(2 hunks)api-test/src/main/resources/masterdata/MachineSpecification/UpdateMachineSpecification.yml(1 hunks)api-test/src/main/resources/masterdata/MachineType/CreateMachineType.yml(1 hunks)api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml(1 hunks)api-test/src/main/resources/masterdata/RegCenterType/UpdateRegCenterType.yml(5 hunks)api-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.yml(9 hunks)api-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.yml(17 hunks)api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml(7 hunks)api-test/src/main/resources/masterdata/Template/CreateTemplate.yml(7 hunks)api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml(5 hunks)api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml(1 hunks)api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml(2 hunks)api-test/src/main/resources/masterdata/UpdateDocType/UpdateDocType.yml(3 hunks)api-test/src/main/resources/masterdata/UpdateMachineTypeStatus/UpdateMachineTypeStatus.yml(1 hunks)api-test/src/main/resources/masterdata/UserCenterMapping/UpdateUserCenterMapping.yml(2 hunks)api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml(1 hunks)api-test/testNgXmlFiles/masterdataSuite.xml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (24)
- api-test/src/main/resources/masterdata/DeleteDocumentType/deleteDocumentType.yml
- api-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.yml
- api-test/src/main/resources/masterdata/UserCenterMapping/UpdateUserCenterMapping.yml
- api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml
- api-test/src/main/resources/masterdata/MachineType/CreateMachineType.yml
- api-test/src/main/resources/masterdata/RegCenterType/UpdateRegCenterType.yml
- api-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.yml
- api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml
- api-test/src/main/resources/masterdata/BlockListedWords/UpdateBlockListedWords.yml
- api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml
- api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml
- api-test/src/main/resources/masterdata/UpdateMachineTypeStatus/UpdateMachineTypeStatus.yml
- api-test/src/main/resources/masterdata/Machine/CreateMachine.yml
- api-test/src/main/resources/masterdata/Template/CreateTemplate.yml
- api-test/src/main/resources/masterdata/FetchTemplate/FetchTemplate.yml
- api-test/src/main/resources/masterdata/UpdateDocType/UpdateDocType.yml
- api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml
- api-test/src/main/resources/masterdata/MachineSpecification/CreateMachineSpecification.yml
- api-test/src/main/resources/masterdata/GetRegistrationMachineUserMappingHistory/GetRegistrationMachineUserMappingHistory.yml
- api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml
- api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml
- api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml
- api-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.yml
- api-test/src/main/resources/masterdata/Device/CreateDevice.yml
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-15T02:35:40.457Z
Learnt from: GOKULRAJ136
Repo: mosip/admin-services PR: 1285
File: db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql:31-31
Timestamp: 2025-11-15T02:35:40.457Z
Learning: In the mosip/admin-services repository, the master.blocklisted_words table schema in db_release_scripts/mosip_master/ddl/master-blocklisted_words.sql is the authoritative version with composite PRIMARY KEY (word, lang_code) and lang_code NOT NULL to support multilingual entries. This was intentionally introduced during seed and default data updates (MOSIP-28207), with corresponding data updates in mosip-data.
Applied to files:
api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml
📚 Learning: 2025-12-12T12:21:28.887Z
Learnt from: Rakshithasai123
Repo: mosip/admin-services PR: 0
File: :0-0
Timestamp: 2025-12-12T12:21:28.887Z
Learning: " || echo "NOT FOUND - correctly removed"
echo -e "\n--- ModelMapper ---"
grep -r "modelmapper" admin/*/pom.xml | grep -E "artifactId|dependency" || echo "NOT FOUND - correctly removed"
echo -e "\n--- Log4j API ---"
grep -r "log4j-api" admin/*/pom.xml | grep -v "exclusion" | grep -E "dependency|artifactId" || echo "NOT FOUND (only exclusions) - correctly removed"
echo -e "\n\n=== STEP 6: Verify all licenses from SBOM match user's NOTICES ==="
cat sbom_final_check.json | jq -r '.packages[] | select(.licenseConcluded != "NOASSERTION" and .licenseConcluded != null) | "\(.name)|\(.versionInfo // "NO_VERSION")|\(.licenseConcluded)"' | sort -u | head -50
```
Length of output: 14287
---
</details>
Rakshithasai123
Short answer: it’s not accurate yet. Here’s what the scripts found and what to fix, followed by a ready‑to‑paste corrected THIRD-PARTY-NOTICES and the requested copyright+license text blocks.
What’s wrong in the current file (from your repository)
- Remove: JSON Simple, Mo...
Applied to files:
api-test/testNgXmlFiles/masterdataSuite.xml
🔇 Additional comments (15)
api-test/src/main/resources/masterdata/DeleteRegCenterType/DeleteRegCenterType.yml (1)
8-8: LGTM! Proper test dependency declared.The addition of
additionalDependenciescorrectly ensures that the registration center type is created before this deletion test executes.api-test/src/main/resources/masterdata/FilterMachineSpec/FilterMachineSpec.yml (1)
9-9: LGTM! Consistent dependency additions for valid filter tests.The
additionalDependenciesfield is correctly added to all valid filter test cases (TC_01 through TC_06) that expect machine specification data to exist. The dependency onTC_Masterdata_CreateMachineSpecification_01ensures that prerequisite data is created before these filter tests execute. Error/invalid test cases (TC_08-13) appropriately exclude this dependency since they test error handling rather than data filtering.Also applies to: 36-36, 63-63, 90-90, 117-117, 144-144
api-test/testNgXmlFiles/masterdataSuite.xml (1)
1337-1344: XML comments properly formatted.The malformed XML comments flagged in the previous review (for MOSIP-33731) have been correctly formatted with proper
<!--and-->delimiters. The test blocks are now properly structured.Also applies to: 1481-1488
api-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.yml (2)
52-52: LGTM! Consistent dependency declaration across all test cases.The
additionalDependenciesfield is consistently added to all 17 test cases, which correctly reflects that each test relies on data from the CreateDocumentType test. This explicit dependency declaration improves test orchestration and makes dependencies transparent.Also applies to: 95-95, 138-138, 177-177, 216-216, 250-250, 289-289, 328-328, 367-367, 406-406, 445-445, 484-484, 523-523, 561-561, 600-600, 638-638
9-9: Dependency identifier verified and correctly established.The addition of
additionalDependencies: TC_Masterdata_CreateDocumentType_01is correct. The referenced test case exists in CreateDocumentType.yml with matching uniqueIdentifier, and all data patterns ($ID:CreateDocumentType_Valid_Smoke_Sid_name$and$ID:CreateDocumentType_Valid_Smoke_Sid_code$) referenced across all 17 test cases map correctly to the CreateDocumentType_Valid_Smoke_Sid test data.api-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.yml (1)
9-9: LGTM! Dependency declarations properly align with test data references.The
additionalDependencies: TC_Masterdata_CreateDeviceType_01field has been consistently added to all DeviceTypeFilter test cases, ensuring that the prerequisite device type data created by the CreateDeviceType test is available before these filter tests execute. This is essential since the test inputs reference$ID:CreateDeviceType_All_Valid_Mandatory_Fields_Smoke_Sid_code$.Also applies to: 36-36, 63-63, 90-90, 118-118, 140-140, 166-166, 193-193
api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml (1)
9-9: LGTM! Dependency declarations properly support update test prerequisites.The
additionalDependencies: TC_Masterdata_CreateDeviceType_01field has been added to all UpdateDeviceType test cases, ensuring the device type entities exist before update operations are attempted. The tests reference variables such as$ID:CreateDeviceType_All_Valid_Smoke_Sid_code$and$ID:CreateDeviceType_All_Valid_Mandatory_Fields_Smoke_Sid_code$, which confirms these dependencies are required.Also applies to: 30-30, 51-51, 77-77, 103-103, 129-129, 155-155, 181-181, 207-207
api-test/src/main/resources/masterdata/MachineType/UpdateMachineType.yml (1)
12-12: Case correction aligns with test case identifier rename.The variable references have been correctly updated from
$ID:CreateMachineType_All_Valid_Smoke_Sid_code$to$ID:CreateMachineType_All_Valid_Smoke_sid_code$(note the case change fromSidtosid). This aligns with the rename in CreateMachineType.yml from Masterdata_CreateMachineType_All_Valid_Smoke_Sid to Masterdata_CreateMachineType_All_Valid_Smoke_sid. This consistency is critical for the test to locate the correct prerequisite data.Also applies to: 16-16, 20-20
api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml (1)
52-52: Verify if negative validation tests require create dependencies.Test cases 3-9 are validation tests using hardcoded or invalid code values. Confirm whether these tests actually require the create test dependency
TC_Masterdata_CreateDocumentCategory_01, or if they only need it when the hardcoded codes (like "DocTestCode01") are created by the prerequisite test.#!/bin/bash # Description: Check if hardcoded codes like "DocTestCode01" are created in the create test # Search for "DocTestCode01" in CreateDocumentCategory test file rg -n 'DocTestCode01' api-test/src/main/resources/masterdata/DocumentCategory/CreateDocumentCategory.yml # Also check if validation tests typically have dependencies rg -n 'additionalDependencies' api-test/src/main/resources/masterdata/DocumentCategory/CreateDocumentCategory.ymlAlso applies to: 78-78, 104-104, 130-130, 156-156, 182-182, 208-208
api-test/src/main/resources/masterdata/MachineSpecification/UpdateMachineSpecification.yml (1)
18-18: Casing correction verified—reference exists and is consistent across the test suite.The
machineTypeCodereference toCreateMachineType_All_Valid_Smoke_sid_code(lowercase 'sid') is correct. The source test caseMasterdata_CreateMachineType_All_Valid_Smoke_sidexists in CreateMachineType.yml with matching lowercase casing. Consistent usage across UpdateMachineType.yml and other test files confirms this standardization is complete.api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml (1)
24-24: Questionable dependency for negative test case.The invalid word test uses a hardcoded non-existent word
"notexist"(line 28) and expects a "not found" error. The dependency onTC_Masterdata_CreateBlockListedWords_01seems unnecessary for this negative test case unless it's required for system initialization or API availability.Please clarify whether this dependency is needed for system state initialization, or if it can be removed for this negative test case.
api-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml (1)
9-9: LGTM! Logical test dependency added.The
additionalDependenciesonTC_Masterdata_CreateBlockListedWords_01is appropriate for a delete operation, ensuring the prerequisite data exists before deletion is attempted. The referenced test case is confirmed to exist.api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml (3)
10-10: Good addition of explicit dependencies for positive test cases.Adding
additionalDependencies: TC_Masterdata_CreateRegCenter_01to all positive/smoke test cases correctly formalizes the prerequisite that a registration center must be created before it can be fetched. Many of these tests already referenced dynamic data from the CreateRegCenter test (e.g.,$ID:CreateRegCenter_allValid_smoke_sid_id$), so this makes the dependency explicit and ensures proper test execution order.Also applies to: 37-37, 127-127, 186-186, 245-245, 273-273, 365-365, 391-391, 481-481, 540-540, 636-636, 695-695, 820-820
10-10: No action needed. TheadditionalDependenciesfield already supports multiple values through comma-separated format (e.g.,TC_Masterdata_CreateRegCenter_01,TC_Masterdata_Other_Dependency), and the single-value format used here is correct and consistent with the framework's design pattern.Likely an incorrect or invalid review comment.
63-63: The negative test cases appropriately depend on registration center creation.The 18 negative test cases (lines 63, 94, 152, 212, 300, 332, 418, 449, 507, 570, 602, 662, 723, 756, 788, 848, 881, 914) test database query error scenarios, not pure input format validation. They use invalid values (e.g., "34117" latitude, "-63275" longitude, "1009393901" registration center ID) and expect corresponding error responses ("Registration Center not found"). These tests verify that the API correctly searches the database and returns appropriate error codes when criteria don't match any existing data. The
TC_Masterdata_CreateRegCenter_01dependency is necessary to ensure the database is initialized and queryable, providing a stable test environment for validating error-handling behavior.
api-test/src/main/java/io/mosip/testrig/apirig/masterdata/utils/MasterDataUtil.java
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
api-test/src/main/resources/masterdata/DeleteBlockListedWords/DeleteBlockListedWords.yml
Outdated
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/DeleteDocumentCategory/deleteDocumentCategory.yml
Outdated
Show resolved
Hide resolved
Signed-off-by: Jayesh Kharode <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
api-test/src/main/resources/config/testCaseInterDependency.json (1)
1-552: Fix undefined test case references in dependency configuration.This file defines test case interdependencies but contains 18 references to test cases that are not defined as keys in the configuration:
- TC_Masterdata_BulkUpload_01, TC_Masterdata_BulkUpload_02
- TC_Masterdata_CreateBlockListedWords_01, TC_Masterdata_CreateDeviceType_01, TC_Masterdata_CreateDeviceType_03
- TC_Masterdata_CreateDocumentCategory_01, TC_Masterdata_CreateDocumentCategory_02
- TC_Masterdata_CreateDocumentType_01, TC_Masterdata_CreateDocumentType_02
- TC_Masterdata_CreateDynamicField_01, TC_Masterdata_CreateDynamicField_02
- TC_Masterdata_CreateHoliday_01, TC_Masterdata_CreateLocationData_01
- TC_Masterdata_CreateMachineSpecification_01, TC_Masterdata_CreateMachineType_01
- TC_Masterdata_CreateRegCenter_01, TC_Masterdata_CreateRegCenterType_01
- TC_Masterdata_CreateTemplate_01, TC_Masterdata_CreateTemplateFileFormat_01
- TC_Masterdata_CreateTemplateType_01, TC_Masterdata_CreateZoneUser_01
- TC_Masterdata_UpdateBlockListedWordStatus_01, TC_Masterdata_UpdateLocationStatus_01
- TC_Masterdata_UpdateMachineTypeStatus_01, TC_Masterdata_UpdateRegCentStatus_01
- TC_Masterdata_UpdateZoneUserStatus_01, TC_Masterdata_PacketRejectionReasonCategory_01
Either define these test cases or remove/replace the references.
🧹 Nitpick comments (3)
api-test/src/main/resources/masterdata/FilterRegCenterType/FilterRegCenterType.yml (1)
112-133: Consider adding dependency to TC_05 for clearer test semantics.TC_05 tests filtering with invalid text and expects
totalCount: "0". While this works without the dependency (no data + no matches = zero), having the dependency would make the test semantics clearer: it would explicitly test "valid data exists, but this filter text matches none of it" rather than potentially testing "no data exists at all."This is optional and the current implementation is functional, but adding the dependency would strengthen the test's intent.
🔎 Optional enhancement
MasterData_FilterRegCenterType_inValid_filterText: endPoint: /v1/masterdata/registrationcentertypes/filtervalues uniqueIdentifier: TC_Masterdata_FilterRegCenterType_05 description: Filter Registration Center Type details by invalid filter text role: admin checkErrorsOnlyInResponse: true templateFields: ["languageCode"] restMethod: post + additionalDependencies: TC_Masterdata_CreateRegCenterType_01 inputTemplate: masterdata/FilterRegCenterType/filterRegCenterType outputTemplate: masterdata/NilFilterResultapi-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml (1)
57-173: Clarify dependency rationale for coordinate/location validation tests.Three negative test cases (TC_03, TC_04, TC_06 at lines 57-86, 87-116, 144-173) that validate invalid coordinates and locations lack
additionalDependencies: TC_Masterdata_CreateRegCenter_01, while other test cases throughout the file include it (e.g., TC_05, TC_08, TC_18).However, the three missing dependencies all test input validation (invalid latitude, longitude, locationcode) rather than data retrieval. This pattern suggests they may intentionally avoid the dependency since validating malformed input parameters doesn't require pre-created test data.
Please confirm whether this is intentional design—tests validating input parameters need no setup dependency, while tests retrieving data require the dependency—or if all test cases should be unified under a single dependency pattern.
api-test/src/main/resources/config/testCaseInterDependency.json (1)
10-19: Review the consistency and necessity of dependencies for GetRegistrationMachineUserMappingHistory_01.This test has 8 dependencies, including multiple Create and Update operations. Some dependencies appear redundant:
UpdateMachineStatus_01depends onCreateMachine_01→ redundant (already listed)UpdateZoneUserStatus_01depends onCreateZoneUser_01→ redundant (already listed)SearchMachine_01depends onCreateMachine_01→ redundant (already listed)However, inconsistencies also exist:
UpdateMachineTypeStatus_01requiresCreateMachineType_01(not in dependencies)UpdateMachineSpecification_01requiresCreateMachineType_01andCreateMachineSpecification_01(neither in dependencies)Either these missing Create operations should be added, or the Update operations can be removed if their full dependency chain is not required. Clarify whether this test needs the direct Create dependencies or if they can be satisfied transitively through the Update operations.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
api-test/src/main/resources/config/testCaseInterDependency.jsonapi-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.ymlapi-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.ymlapi-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.ymlapi-test/src/main/resources/masterdata/DeviceTypeSearch/DeviceTypeSearch.ymlapi-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.ymlapi-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.ymlapi-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.ymlapi-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.ymlapi-test/src/main/resources/masterdata/FilterDocumentType/FilterDocumentType.ymlapi-test/src/main/resources/masterdata/FilterRegCenterType/FilterRegCenterType.ymlapi-test/src/main/resources/masterdata/Machine/CreateMachine.ymlapi-test/src/main/resources/masterdata/RegistrationCenter/CreateRegistrationCenter.ymlapi-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.ymlapi-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.ymlapi-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.ymlapi-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml
🚧 Files skipped from review as they are similar to previous changes (13)
- api-test/src/main/resources/masterdata/RegistrationCenter/CreateRegistrationCenter.yml
- api-test/src/main/resources/masterdata/DocumentCategory/UpdateDocumentCategory.yml
- api-test/src/main/resources/masterdata/DocumentType/UpdateDocumentType.yml
- api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml
- api-test/src/main/resources/masterdata/FilterDocumentType/FilterDocumentType.yml
- api-test/src/main/resources/masterdata/DeviceType/UpdateDeviceType.yml
- api-test/src/main/resources/masterdata/SearchBlockListedWords/SearchBlockListedWords.yml
- api-test/src/main/resources/masterdata/DeviceSpecification/CreateDeviceSpecification.yml
- api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml
- api-test/src/main/resources/masterdata/FilterBlockListedWords/FilterBlockListedWords.yml
- api-test/src/main/resources/masterdata/SearchDocumentType/SearchDocumentType.yml
- api-test/src/main/resources/masterdata/DeviceTypeSearch/DeviceTypeSearch.yml
- api-test/src/main/resources/masterdata/Machine/CreateMachine.yml
🔇 Additional comments (4)
api-test/src/main/resources/masterdata/DeviceTypeFilter/DeviceTypeFilter.yml (2)
9-9: LGTM! Dependency correctly declared.The
additionalDependenciesfield ensures that the device type referenced by$ID:CreateDeviceType_All_Valid_Mandatory_Fields_Smoke_Sid_code$is created before these filter tests execute. This makes the test orchestration more reliable and explicit.Also applies to: 36-36
63-63: The additionalDependency is appropriate.This test filters for active device types (isActive: true) and expects to find at least one matching result. The dependency on TC_Masterdata_CreateDeviceType_01 is necessary since it creates a device type with isActive=true, ensuring the filter test returns valid results.
api-test/src/main/resources/masterdata/FilterRegCenterType/FilterRegCenterType.yml (1)
10-86: Consistent dependency pattern for positive test cases.The
additionalDependencies: TC_Masterdata_CreateRegCenterType_01has been correctly added to all four valid/smoke test cases (TC_01, TC_02, TC_03, TC_04), while negative test cases validating input errors remain without the dependency. This consistent pattern is appropriate if the negative tests are purely validating request structure without requiring database state. The referenced dependency exists inapi-test/src/main/resources/masterdata/RegCenterType/CreateRegCenterType.yml.api-test/src/main/resources/config/testCaseInterDependency.json (1)
1-552: Ensure dependency resolution framework correctly handles transitive dependencies at scale.JSON structure is valid with no self-dependencies detected. The configuration contains 341 test cases with 420 dependency declarations (average 1.23 per test). The highest-dependency test case has 8 dependencies.
While the dependency structure is sound, add test coverage to verify:
- Transitive dependency resolution works correctly—if TC_A depends on TC_B and TC_B depends on TC_C, confirm TC_A properly waits for TC_C to complete.
- Framework prevents execution loops (if any circular paths emerge in future updates).
- Test execution time reports whether these dependencies proportionally reduce parallelization.
These are reasonable safeguards given the test orchestration complexity, even though baseline analysis shows no current structural issues.
2 participants
[MOSIP-43314: Added additional dependencies for masterdata
Summary by CodeRabbit
Bug Fixes
Tests
✏️ Tip: You can customize this high-level summary in your review settings.