MOSIP-44431:Masterdata - Update the test case descriptions to improve…#1343
MOSIP-44431:Masterdata - Update the test case descriptions to improve…#1343Famuda1234 wants to merge 8 commits intomosip:developfrom
Conversation
… clarity Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR replaces and restructures the master configuration properties and updates human-readable descriptions in many masterdata test YAML files to verification-focused wording. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In
`@api-test/src/main/java/io/mosip/testrig/apirig/masterdata/testrunner/MosipTestRunner.java`:
- Around line 104-106: The loop in MosipTestRunner.java that clears and sets
BaseTestCase.languageList uses a hardcoded `i < 1` which will attempt
`localLanguageList.get(0)` even when the source list is empty; modify the loop
to guard against empty lists (e.g., iterate up to Math.min(1,
localLanguageList.size()) or add an explicit check `if
(localLanguageList.isEmpty()) return/continue` before the loop) so that the code
in the block that calls BaseTestCase.languageList.clear() and
BaseTestCase.languageList.add(localLanguageList.get(i)) never executes when
localLanguageList is empty.
In `@api-test/src/main/resources/config/masterdata.properties`:
- Around line 21-42: This file contains hardcoded secrets (keys like
keycloak_Password, postgres-password, audit_password, partner_password, and
mosip_*_client_secret / AuthClientSecret) which must be removed from source;
replace each literal value with a reference to a runtime secret (e.g.,
environment variable names or a single external secrets file path) and update
consumers to read from env or a secret loader instead of masterdata.properties,
add the external secrets file pattern to .gitignore (or ensure env-only usage),
and after changing the file rotate the exposed credentials and purge them from
git history (BFG/git-filter-branch) to eliminate the committed secrets.
In
`@api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml`:
- Line 5: The description field in DeleteUserCenterMapping.yml is truncated
("vali"); update the description value for the test case in
DeleteUserCenterMapping to the full sentence, e.g., "Verify that the system
successfully deletes a user-center mapping when all details are valid", by
editing the description entry in the DeleteUserCenterMapping.yml file (look for
the description key in the DeleteUserCenterMapping test definition).
🧹 Nitpick comments (2)
api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml (1)
20-20: Consider being more specific about what is invalid.The test specifically validates behavior with an invalid ID (line 26), so the description could be more precise by stating "invalid ID" rather than the generic "invalid details".
✨ Suggested improvement
- description: Verify that the system does not delete a user-center mapping when invalid details are provided + description: Verify that the system does not delete a user-center mapping when an invalid ID is providedapi-test/src/main/resources/masterdata/DeviceSpecification/UpdateDeviceSpecification.yml (1)
462-467: Minor:descriptionfield ordering is inconsistent with other test cases.In all other test cases in this file (and across the PR),
descriptionappears immediately afteruniqueIdentifier. Here it's placed aftertemplateFields(Lines 465-467). Consider reordering for consistency.Suggested reorder
MasterData_UpdateDeviceSpecification_InputParameter_MinDriverversion_AboveMaxLen16: endPoint: /v1/masterdata/devicespecifications uniqueIdentifier: TC_Masterdata_UpdateDeviceSpecification_17 + description: Verify that the system does not update a device specification when the minimum driver version exceeds 16 characters role: admin templateFields: ["name","description"] - description: Verify that the system does not update a device specification when the minimum driver version exceeds 16 characters restMethod: put
api-test/src/main/java/io/mosip/testrig/apirig/masterdata/testrunner/MosipTestRunner.java
Outdated
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml
Show resolved
Hide resolved
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/masterdata.properties (1)
139-152: 🛠️ Refactor suggestion | 🟠 MajorDocument how to populate empty secrets at runtime.
The hardcoded secrets issue from the previous review has been properly addressed by using empty placeholders. However, there's no documentation explaining how these should be populated at runtime (e.g., via environment variables, external secrets file, or secrets management service).
Adding documentation will help users deploy this correctly without accidentally committing secrets.
📝 Suggested documentation addition
Add a comment block above line 139:
`#----------------------------------` Client Secret Keys -----------------------# `#--` When test rig ran in docker, these values derived from the environment ---# # # IMPORTANT: Do not hardcode secrets in this file. # These values should be provided at runtime via: # - Environment variables (recommended): export mosip_partner_client_secret=<value> # - External secrets file: Specify path via -Dsecrets.file=<path> # - Secrets management service: AWS Secrets Manager, HashiCorp Vault, etc. # # Example using environment variables: # mosip_partner_client_secret = ${mosip_partner_client_secret} #
🤖 Fix all issues with AI agents
In `@api-test/src/main/resources/config/masterdata.properties`:
- Around line 254-260: The properties OTPTimeOut, attempt, ConfigParameters, and
langselect in masterdata.properties appear unused; either remove them to reduce
config clutter or add documentation comments above each explaining intended
purpose, valid values, and where they are consumed (e.g., OTPTimeOut -> OTP
expiry in seconds, attempt -> retry count, ConfigParameters -> comma-separated
keys, langselect -> environment language selector). Update the file by deleting
unused lines or replacing them with commented descriptions and example values,
and if you keep them, add a short comment referencing the related feature or
future ticket/constant name so their purpose is clear (refer to property names
OTPTimeOut, attempt, ConfigParameters, langselect).
🧹 Nitpick comments (3)
api-test/src/main/resources/config/masterdata.properties (3)
111-111: Minor typo in comment."dervied" should be "derived". This typo appears in multiple section headers (lines 111, 124, 140, 167, 190).
✏️ Suggested fix
-#-- When test rig ran in docker, these values dervied from the environment ---# +#-- When test rig ran in docker, these values derived from the environment ---#Apply this fix to all occurrences (lines 111, 124, 140, 167, 190).
189-219: Document required vs. optional DB configuration values.Multiple DB-related properties are empty, including passwords (lines 198, 204, 216) and infrastructure values like
DB_PORT(line 200) andinstallation-domain(line 201). While empty passwords are correct for security, empty infrastructure values may cause runtime failures.Consider adding comments indicating:
- Which properties are required vs. optional
- Default values if applicable
- How these should be provided (environment variables, etc.)
270-271: Clarify the purpose of the commented-out configuration.Line 271 contains a commented-out configuration that appears to be an example for
mosip_components_base_urls. Consider adding a comment to clarify whether this is:
- An example format for users to follow
- Deprecated configuration that should be removed
- A template to be uncommented in certain scenarios
📝 Example clarification
mosip_components_base_urls= -#auditmanager=api-internal.released.mosip.net;idrepository=api-internal.released.mosip.net;partnermanager=api-internal.released.mosip.net;idauthentication=api-internal.released.mosip.net;policymanager=api-internal.released.mosip.net;authmanager=api-internal.released.mosip.net;resident=api-internal.released.mosip.net;preregistration=api-internal.released.mosip.net;masterdata=api-internal.released.mosip.net;idgenerator=api-internal.released.mosip.net; +# Example format (semicolon-separated component=host pairs): +# mosip_components_base_urls=auditmanager=api-internal.example.net;idrepository=api-internal.example.net
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
There was a problem hiding this comment.
Actionable comments posted: 17
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/GenderFilter/GenderFilter.yml (2)
79-104:⚠️ Potential issue | 🟡 MinorDescription does not match the test — the empty field is
type, nottext.Line 82 says "when the filter text is empty," but the actual input on line 91 has
"type": ""(empty type) while"text"is"Genderdummy". The error response also confirms:"Filter Type cannot be empty or null". The description should reference the filter type being empty, not the text.Proposed fix
- description: Verify that the system successfully processes the request and returns appropriate results when the filter text is empty while filtering gender entries + description: Verify that the system returns an error when the filter type is empty while filtering gender entries🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/GenderFilter/GenderFilter.yml` around lines 79 - 104, The test case Masterdata_GenderFilter_ValidTextAsEmpty_Smoke has an incorrect description: the input shows "type": "" (empty) while "text" is "Genderdummy" and the expected error is about the filter type; update the description to say the filter type is empty (e.g., "Verify system behavior when the filter type is empty") and, if templateFields should reflect the dynamic fields used in the input, add "type" to templateFields (replace or augment ["text"] with ["type","text"]) so the metadata matches the payload.
203-223:⚠️ Potential issue | 🟡 MinorDescription says "returns an error" but the test expects an empty result set, not an error.
Line 206 states the system "returns an error," but the
outputTemplateon line 211 isgenderFilterResult(notmasterdata/error), and the expected output on line 222 is{"filters": []}— a successful response with no matches. The description should reflect that the system returns an empty result set for non-matching text.Proposed fix
- description: Verify that the system returns an error when a non-existing filter text is provided while filtering gender entries + description: Verify that the system returns an empty result set when a non-existing filter text is provided while filtering gender entries🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/GenderFilter/GenderFilter.yml` around lines 203 - 223, The test case Masterdata_GenderFilter_InValidTextAsNonExisting has a misleading description; change the description field to state that the system returns an empty result set (no matches) when a non-existing filter text is provided rather than saying it "returns an error", and keep the existing outputTemplate (genderFilterResult) and expected output {"filters": []} unchanged so the description matches the test assertions.api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml (1)
871-884:⚠️ Potential issue | 🟡 MinorDescription says "language code is missing" but the test actually sends an invalid language code.
The input on line 884 provides
"langcode": "hhgghaJ"— this is not a missing value but an invalid one. The test name also saysWithout_langCode, but the description should still accurately describe the actual test behavior.✏️ Suggested fix
- description: Verify that the system returns an error when language code is missing while fetching paginated registration center records by hierarchy level and text + description: Verify that the system returns an error when an invalid language code is used to fetch paginated registration center records by hierarchy level and text🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml` around lines 871 - 884, The test case MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg (uniqueIdentifier TC_Masterdata_FetchRegCent_30) has a mismatch: the description/name claim the language code is missing but the input contains an invalid langcode ("hhgghaJ"); update either the input or the metadata so they match—either remove/omit the "langcode" field (or set it to the $REMOVE$ token) in the input template to truly test a missing langcode, or change the test name/description to indicate "invalid langcode" and keep the current input; ensure you edit the description and the test identifier text (MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg and description string) or the input's "langcode" field accordingly.
🧹 Nitpick comments (4)
api-test/src/main/resources/masterdata/GetUserDetailsByIdAndEffDate/GetUserDetailsByIdAndEffDate.yml (1)
38-38: Pre-existing typo in test key:GetUserDetailsByIsAndEffDate→GetUserDetailsByIdAndEffDate.Since this PR is about improving clarity, it would be a good opportunity to also fix this typo (
Is→Id) in the test case key name on this line.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/GetUserDetailsByIdAndEffDate/GetUserDetailsByIdAndEffDate.yml` at line 38, Rename the mistaken test key MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate to MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate; locate the entry named MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate in GetUserDetailsByIdAndEffDate.yml and update the string `Is` → `Id` so the key reads MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate consistently.api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml (1)
434-434: Minor punctuation inconsistency: trailing period.Line 434 ends with a period (
.) while the other descriptions in this file do not. Consider removing it for consistency.Proposed fix
- description: Verify that the system returns applicant type entries correctly when FLE, NFR, and CHL flags are set to true. + description: Verify that the system returns applicant type entries correctly when FLE, NFR, and CHL flags are set to true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml` at line 434, The description string "Verify that the system returns applicant type entries correctly when FLE, NFR, and CHL flags are set to true." has a trailing period that is inconsistent with other descriptions; remove the final period so the description ends without punctuation. Locate the YAML entry with the description field in GetApplicantType.yml (the line containing that exact description text) and update it to match the punctuation style used elsewhere.api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml (2)
532-532: Same inconsistency: missing "successfully" in this positive-path description.TC_19 also omits "successfully" — see note on TC_13 above.
✏️ Suggested fix
- description: Verify that the system fetches registration center records with pagination by hierarchy level and text using a valid language code + description: Verify that the system successfully fetches registration center records with pagination by hierarchy level and text using a valid language code🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml` at line 532, Update the positive-path test descriptions to include the word "successfully": edit the description fields in FetchRegCent.yml for the relevant test cases (e.g., the description for TC_19 and TC_13) so they read "...successfully fetches registration center records..." (or similar) instead of the current phrasing; locate the description entries by the test case IDs TC_19 and TC_13 and adjust the description strings accordingly.
357-357: Minor inconsistency: this positive-path description omits "successfully" unlike other positive test cases.Other positive test descriptions use "successfully fetches" (e.g., TC_01, TC_02, TC_05). This one just says "fetches". Consider aligning for consistency.
✏️ Suggested fix
- description: Verify that the system fetches registration center records by hierarchy level and list of text using a valid language code. + description: Verify that the system successfully fetches registration center records by hierarchy level and list of text using a valid language code🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml` at line 357, Update the description field in this test case to match other positive-path wording by inserting "successfully" so it reads: "Verify that the system successfully fetches registration center records by hierarchy level and list of text using a valid language code." Edit the description entry in FetchRegCent.yml (the test case's description property) to apply this exact phrasing for consistency with TC_01/TC_02/TC_05.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@api-test/src/main/resources/masterdata/DeviceType/CreateDeviceType.yml`:
- Line 67: The test description is inaccurate: it asserts a duplicate-code error
(KER-MSD-053) because the payload reuses "code": "AUTO3$TESTDATACONTEXT$" (same
as TC_01), not a duplicate name; update the description in CreateDeviceType.yml
to say it verifies that creating a device type with a duplicate code is rejected
(mention KER-MSD-053) and ensure any textual references to "name" in this test
are replaced with "code" so the intent matches the asserted error.
In
`@api-test/src/main/resources/masterdata/FetchAllDocumentCategories/FetchAllDocumentCategories.yml`:
- Line 5: The test description in FetchAllDocumentCategories.yml incorrectly
mentions "language code and code filters" even though the request to
/documentcategories/all has no input; update the YAML 'description' value to a
concise, accurate sentence such as "Verify that the system can fetch all
document categories successfully" (or similar) so it reflects the actual test
behavior.
In `@api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml`:
- Line 86: There is a wording typo in the YAML description: replace the
nonstandard word "unexisting" with "non-existent" in the description string used
by FetchDevice (the description field in FetchDevice.yml) so it reads "Verify
that the system returns an error when a non-existent device type is used to
fetch device records".
In `@api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml`:
- Line 56: Update the description string in the FetchDeviceSpec test YAML where
it currently reads "unexisting device type code" to use the correct term
"non-existent device type code"; locate the description field under the
FetchDeviceSpec.yml test case (the line that starts with description: Verify
that the system returns an error when an unexisting device type code is used to
fetch device specification records) and replace "unexisting" with
"non-existent".
In `@api-test/src/main/resources/masterdata/FetchHolidays/FetchHoliday.yml`:
- Line 55: The description strings containing the phrase "unexisting" (e.g.,
"Verify that the system returns an error when an unexisting holiday ID is used
to fetch holiday records") should be updated to use standard English—replace
"unexisting" with "non-existing" or "nonexistent" consistently across all
occurrences (including the other similar descriptions noted in the file). Locate
the exact description lines in FetchHoliday.yml and perform a find-and-replace
of "unexisting" → "nonexistent" (or "non-existing") so all three instances are
corrected.
In `@api-test/src/main/resources/masterdata/FetchIdSchema/FetchIdSchema.yml`:
- Around line 3-5: The test description incorrectly says it "fetches all ID
schema records" while the endPoint is /v1/masterdata/idschema/latest; update the
description in FetchIdSchema.yml (uniqueIdentifier
TC_Masterdata_FetchIdSchema_01, endPoint /v1/masterdata/idschema/latest) to
state that it verifies fetching the latest ID schema (for a given/valid language
code) — wording must clearly differ from the FetchAllIdschema test to avoid
confusion.
In `@api-test/src/main/resources/masterdata/FetchLocation/FetchLocation.yml`:
- Line 111: Update the duplicate test descriptions so TC_06 and TC_09 are
clearly distinct: change TC_06's description to reference both parameters and
its endpoint (e.g., "Verify that the system successfully fetches location
details for a given locationcode and langcode via
/locations/info/{locationcode}/{langcode}") and change TC_09's description to
reference its endpoint and scope (e.g., "Verify that the system successfully
fetches location level data for a given langcode via
/locations/level/{langcode}"); edit the description fields for the tests
identified as TC_06 and TC_09 to use these clearer, endpoint-specific phrasings.
- Line 228: Update the test description for TC_12 in FetchLocation.yml so it
accurately reflects the expected output: change the sentence that says the
system "returns an error" to state that the system returns a validation status
"Invalid" (e.g., "Verify that the system returns a validation status of
'Invalid' when an invalid location name is used to fetch location details");
locate the TC_12 test block in FetchLocation.yml to make this exact wording
change.
In
`@api-test/src/main/resources/masterdata/FetchMissingDynamicField/FetchMissingDynamicField.yml`:
- Line 5: Update the YAML test descriptions so TC_01 and TC_02 are distinct:
change TC_01's description (currently phrased as "Verify that the system
successfully fetches all missing dynamic field records with valid input data")
to explicitly state it tests fetching missing dynamic fields when fieldName is
null (no specific field filter), and change TC_02's description to explicitly
state it tests fetching missing dynamic fields for a specific fieldName
("description"); locate the two descriptions by the test IDs TC_01 and TC_02 in
FetchMissingDynamicField.yml and replace the generic text with these clarified,
scenario-specific descriptions.
In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Around line 838-841: The test case
MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_langCode_MorePageSize_Neg
has a misleading description: the endpoint query uses pageNumber=100&pageSize=5
so the failure is due to an out-of-range page number, not an oversized page
size; update the description field for this YAML entry to state that it verifies
an error is returned when the page number is out of range (e.g., "Verify that
the system returns an error when an out-of-range page number is used to fetch
paginated registration center records by hierarchy level and language code") so
it accurately matches the endPoint and intent.
In
`@api-test/src/main/resources/masterdata/FetchRegCentDeviceHistory/FetchRegCentDeviceHistory.yml`:
- Line 71: The test case description string in the FetchRegCentDeviceHistory
YAML has inconsistent capitalization—change the description value from "verify
that the system returns an error when invalid effective date-time values are
provided while fetching the registration center device history" to start with a
capital "V" ("Verify ...") so it matches the other test descriptions; update the
description field in the FetchRegCentDeviceHistory.yml test case accordingly.
In `@api-test/src/main/resources/masterdata/FilterHolidays/FilterHolidays.yml`:
- Line 27: TC_02 and TC_09 in FilterHolidays.yml share identical descriptions
but test different filter columns and expectations; update each test description
to mention the specific column and expected result (e.g., TC_02: "Verify
filtering by isActive returns totalCount: 0 when invalid filter text is
provided" and TC_09: "Verify filtering by holidayName returns an empty response
when invalid filter text is provided") so test reports are unambiguous and
easier to triage.
In
`@api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml`:
- Line 682: The description for TC_22
(Masterdata_GetApplicantType_DOB_lessThanAYear) is misleading — it says the
system should return an error or handle gracefully, but the test expects a
successful response (uses outputTemplate
masterdata/GetApplicantType/getApplicantTypeResult and asserts applicantTypeCode
"005"). Update the description to reflect the expected success outcome, e.g.,
"Verify that the system returns the correct applicant type when the date of
birth is less than a year old," so it matches the test case name and expected
output.
In
`@api-test/src/main/resources/masterdata/GetHolidaysMissingIds/GetHolidaysMissingIds.yml`:
- Around line 18-21: Fix the typo in the test case key by renaming
Admin_GetHolidaysMissingIds_InValid_Inavild_langCode to a correct, clear key
(e.g., Admin_GetHolidaysMissingIds_InValid_Invalid_langCode or
Admin_GetHolidaysMissingIds_Invalid_langCode) in GetHolidaysMissingIds.yml;
update any external references (test runners, reports, skip lists, or other YAML
entries) that use the old key so they point to the new key to avoid breaking
test resolution.
In
`@api-test/src/main/resources/masterdata/GetMissingDocumentTypeByLangcode/GetMissingDocumentTypeByLangcode.yml`:
- Line 5: Update the YAML test descriptions to reflect that this endpoint
returns missing document type IDs rather than all document types: change both
description fields in GetMissingDocumentTypeByLangcode (and the duplicated case
at 20-20) to mention "missing document types" or "missing document type IDs" and
include the endpoint path /documenttypes/missingids/{langcode} or the test name
GetMissingDocumentTypeByLangcode to clarify the intent.
In
`@api-test/src/main/resources/masterdata/GetTemplateFileFormat/GetTemplateFileFormat.yml`:
- Around line 42-45: The test case
Masterdata_GetTemplateFileFormat_langcode_allValid_smoke has an inaccurate
description and a duplicate uniqueIdentifier; update its description to state
that it verifies retrieval of a template file format without a language code
(since the endpoint is /v1/masterdata/templatefileformats/code/{code} and
"langcode" is set to "$REMOVE$") and change the uniqueIdentifier from
TC_Masterdata_GetTemplateFileFormat_02 to TC_Masterdata_GetTemplateFileFormat_03
so it no longer collides with the inValid_code test case.
In `@api-test/src/main/resources/masterdata/GetTemplateType/TemplateType.yml`:
- Line 42: The two test case descriptions in TemplateType.yml are duplicated;
update the description for TC_03 to explicitly state it validates behavior when
both {code} and {langcode} are provided (e.g., "Verify system response when
fetching template types with both {code} and invalid {langcode}") and update
TC_05 to explicitly state it validates behavior when only {langcode} is provided
(e.g., "Verify system response when fetching template types with only an invalid
{langcode}"), locating the descriptions by the test IDs TC_03 and TC_05 in the
file.
---
Outside diff comments:
In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Around line 871-884: The test case
MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg
(uniqueIdentifier TC_Masterdata_FetchRegCent_30) has a mismatch: the
description/name claim the language code is missing but the input contains an
invalid langcode ("hhgghaJ"); update either the input or the metadata so they
match—either remove/omit the "langcode" field (or set it to the $REMOVE$ token)
in the input template to truly test a missing langcode, or change the test
name/description to indicate "invalid langcode" and keep the current input;
ensure you edit the description and the test identifier text
(MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg
and description string) or the input's "langcode" field accordingly.
In `@api-test/src/main/resources/masterdata/GenderFilter/GenderFilter.yml`:
- Around line 79-104: The test case
Masterdata_GenderFilter_ValidTextAsEmpty_Smoke has an incorrect description: the
input shows "type": "" (empty) while "text" is "Genderdummy" and the expected
error is about the filter type; update the description to say the filter type is
empty (e.g., "Verify system behavior when the filter type is empty") and, if
templateFields should reflect the dynamic fields used in the input, add "type"
to templateFields (replace or augment ["text"] with ["type","text"]) so the
metadata matches the payload.
- Around line 203-223: The test case
Masterdata_GenderFilter_InValidTextAsNonExisting has a misleading description;
change the description field to state that the system returns an empty result
set (no matches) when a non-existing filter text is provided rather than saying
it "returns an error", and keep the existing outputTemplate (genderFilterResult)
and expected output {"filters": []} unchanged so the description matches the
test assertions.
---
Nitpick comments:
In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Line 532: Update the positive-path test descriptions to include the word
"successfully": edit the description fields in FetchRegCent.yml for the relevant
test cases (e.g., the description for TC_19 and TC_13) so they read
"...successfully fetches registration center records..." (or similar) instead of
the current phrasing; locate the description entries by the test case IDs TC_19
and TC_13 and adjust the description strings accordingly.
- Line 357: Update the description field in this test case to match other
positive-path wording by inserting "successfully" so it reads: "Verify that the
system successfully fetches registration center records by hierarchy level and
list of text using a valid language code." Edit the description entry in
FetchRegCent.yml (the test case's description property) to apply this exact
phrasing for consistency with TC_01/TC_02/TC_05.
In
`@api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml`:
- Line 434: The description string "Verify that the system returns applicant
type entries correctly when FLE, NFR, and CHL flags are set to true." has a
trailing period that is inconsistent with other descriptions; remove the final
period so the description ends without punctuation. Locate the YAML entry with
the description field in GetApplicantType.yml (the line containing that exact
description text) and update it to match the punctuation style used elsewhere.
In
`@api-test/src/main/resources/masterdata/GetUserDetailsByIdAndEffDate/GetUserDetailsByIdAndEffDate.yml`:
- Line 38: Rename the mistaken test key
MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate to
MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate; locate the entry named
MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate in
GetUserDetailsByIdAndEffDate.yml and update the string `Is` → `Id` so the key
reads MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate consistently.
...test/src/main/resources/masterdata/FetchAllDocumentCategories/FetchAllDocumentCategories.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/GetHolidaysMissingIds/GetHolidaysMissingIds.yml
Outdated
Show resolved
Hide resolved
...n/resources/masterdata/GetMissingDocumentTypeByLangcode/GetMissingDocumentTypeByLangcode.yml
Show resolved
Hide resolved
api-test/src/main/resources/masterdata/GetTemplateFileFormat/GetTemplateFileFormat.yml
Show resolved
Hide resolved
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
There was a problem hiding this comment.
Actionable comments posted: 1
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (7)
api-test/src/main/resources/masterdata/ValidDocumentMap/ValidDocumentMap.yml (1)
11-16:⚠️ Potential issue | 🟡 MinorPre-existing mismatch between input
doccategorycodeand expected output message.The input specifies
"doccategorycode":"POA"(line 11), but the expected output message hard-codes"Document Category POB"(line 16). If the output template asserts the full message string, this mismatch will cause the test to fail regardless of the description fix in this PR.🐛 Proposed fix to align the expected message with the input
output: '{ - "status": "mapped", - "message": "Document Category POB - Document Type Mapping doc_auto_test is added successfully" + "status": "mapped", + "message": "Document Category POA - Document Type Mapping doc_auto_test is added successfully" }'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocumentMap/ValidDocumentMap.yml` around lines 11 - 16, The expected output message in ValidDocumentMap.yml hard-codes "Document Category POB" while the input doccategorycode is "POA"; update the output message string under "output" so the message reflects the input doccategorycode (e.g., change "Document Category POB" to "Document Category POA" or make it programmatically interpolate the value) so the status message in the mapping entry matches the "doccategorycode" field.api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml (1)
22-38:⚠️ Potential issue | 🟡 MinorDescription contradicts the actual expected test outcome.
The updated description states "successfully deactivates a device type and reflects the status change correctly", but the test expects an error response —
outputTemplateismasterdata/errorand the expected output asserts error codeKER-MSD-055. Describing a failure path as a success path is misleading, which directly undermines the stated goal of this PR.The description should reflect that the test is verifying an error condition, for example:
✏️ Proposed fix
- description: Verify that the system successfully deactivates a device type and reflects the status change correctly + description: Verify that the system returns an error when attempting to deactivate a device type (e.g., a type that cannot be deactivated)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateDeviceTypeStatus/UpdateDeviceTypeStatus.yml` around lines 22 - 38, The YAML description is inaccurate: it claims a successful deactivation while the test expects an error (outputTemplate: masterdata/error and errors.errorCode: KER-MSD-055). Update the description field in UpdateDeviceTypeStatus.yml to state that the test verifies the service rejects the deactivation and returns the KER-MSD-055 error (e.g., "Verify that attempting to deactivate device type returns error KER-MSD-055 and does not change status"), ensuring the description aligns with the input, outputTemplate, and expected output.api-test/src/main/resources/masterdata/ValidDocumentFilter/ValidDocumentFilter.yml (1)
62-62:⚠️ Potential issue | 🟡 Minor
MasterData_ValidDocumentFilter_InValid_FilterTypedescription was not updated.All other test cases in this file were migrated to verification-focused language, but line 62 still reads
Filter the valid document details with invalid filter type— the old action-oriented phrasing. This leaves the test suite inconsistent with the PR objective.✏️ Suggested fix
- description: Filter the valid document details with invalid filter type + description: Verify that the system returns an error when filtering documents with an invalid FilterType parameter🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocumentFilter/ValidDocumentFilter.yml` at line 62, Update the description for the test case MasterData_ValidDocumentFilter_InValid_FilterType to use verification-focused wording instead of an action phrase; locate the description field (currently "Filter the valid document details with invalid filter type") in ValidDocumentFilter.yml and change it to something like "Verifies behavior when an invalid filter type is provided for valid document lookup" so it matches the other verification-style descriptions.api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml (1)
46-68:⚠️ Potential issue | 🟡 MinorPre-existing mismatch: test name implies blank-description validation, but the expected error is "word not found".
The test scenario
Masterdata_UpdateBlockListedWords_inValid_descriptionBlank(TC_03) and its description both suggest the failure is triggered by a blank description field, but the expected output isKER-MSD-008 "Blocklisted word not found". The word"bullword"does not appear to exist in the test data context, so the error is caused by a missing record rather than a blank description. This is a pre-existing issue and not introduced by this PR, but since the description is being updated here, it's worth aligning the description and test name with the actual failure mode.✏️ Suggested description correction
- description: Verify that the system returns an error when updating blocklisted words with a blank description parameter + description: Verify that the system returns an error when updating a non-existent blocklisted word (word not found)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml` around lines 46 - 68, The test case Masterdata_UpdateBlockListedWords_inValid_descriptionBlank (uniqueIdentifier TC_Masterdata_UpdateBlockListedWordDetails_03) is named and documented as a blank-description validation but its expected output asserts error KER-MSD-008 ("Blocklisted word not found") caused by the input word "bullword"; update the test to align intent and assertion by either (A) changing the description and test name to reflect a missing-word scenario and keep the expected KER-MSD-008, or (B) keep the blank-description intent and change the input/expected output so the request uses an existing word and expects the validation error for blank description; modify the description field and/or the input "word" and output error block accordingly to ensure the test name, description, input, and expected output are consistent.api-test/src/main/resources/masterdata/UpdateMachineTypeStatus/UpdateMachineTypeStatus.yml (1)
10-10:⚠️ Potential issue | 🟡 MinorTypo in template filename and YAML reference should be corrected for consistency.
The filename
updateteMachineTypeStatusResult.hbscontains a strayteand the YAML correctly references this typo'd name. While the template resolves successfully, the filename should match the intended naming convention:updateMachineTypeStatusResult.hbs. Rename the file and update the YAML reference to correct this inconsistency.✏️ Suggested fix
- outputTemplate: masterdata/UpdateMachineTypeStatus/updateteMachineTypeStatusResult + outputTemplate: masterdata/UpdateMachineTypeStatus/updateMachineTypeStatusResult(Also rename the file from
updateteMachineTypeStatusResult.hbstoupdateMachineTypeStatusResult.hbs)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateMachineTypeStatus/UpdateMachineTypeStatus.yml` at line 10, Update the outputTemplate reference and the template file name to remove the stray "te": rename the Handlebars file from updateteMachineTypeStatusResult.hbs to updateMachineTypeStatusResult.hbs and change the YAML value for outputTemplate (currently masterdata/UpdateMachineTypeStatus/updateteMachineTypeStatusResult) to masterdata/UpdateMachineTypeStatus/updateMachineTypeStatusResult so the template name matches across the codebase.api-test/src/main/resources/masterdata/TitleFilter/TitleFilter.yml (2)
84-101:⚠️ Potential issue | 🟡 MinorDescription incorrectly says "returns an error" — the expected output is an empty filter result, not an error.
The
outputTemplateismasterdata/TitleFilter/titleFilterResult(notmasterdata/error) and the expectedoutputis"filters": []. This test verifies that filtering with a non-existent title name returns an empty result set, which is a valid success response — not an error condition. The phrase "negative Name value" is also semantically wrong for a string-valued field.✏️ Proposed fix
- description: Verify that the system returns an error when filtering titles with a negative Name value + description: Verify that the system returns an empty filter result when filtering titles by a Name value that does not exist🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleFilter/TitleFilter.yml` around lines 84 - 101, Update the test description to accurately reflect the expected successful empty result instead of an error: replace the current text "Verify that the system returns an error when filtering titles with a negative Name value" with a clear statement like "Verify that filtering by a non-existent titleName returns an empty result set"; also remove the misleading phrase "negative Name value" and ensure the description aligns with the existing outputTemplate masterdata/TitleFilter/titleFilterResult and the expected output containing "filters": [] (the test uses the "titleName" filter and templateFields "text").
102-127:⚠️ Potential issue | 🟡 MinorRename test case key and fix misleading description—duplicate YAML key and incorrect test classification.
1. Duplicate YAML key:
MasterData_TitleFilter_isActive__eng_smokeis already defined at line 29 (TC_02). The key at line 102 (TC_05) creates a structural conflict; most YAML parsers will silently drop the first occurrence, making TC_02 unreachable.2. Incorrect description: The description claims "successfully filters titles by isActive status in English (smoke test)", but this test:
- Filters by
titleNamewith typebetween(not isActive filtering)- Expects error response
KER-MSD-324 "Received Filter Type not supported"This is a negative test for unsupported filter types, not a smoke test. The description appears to be copied from TC_02 (line 32).
Fix: Rename the key to match its actual behavior and
uniqueIdentifier:- MasterData_TitleFilter_isActive__eng_smoke: + MasterData_TitleFilter_inValid_FilterType_between_neg: endPoint: /v1/masterdata/title/filtervalues uniqueIdentifier: TC_Masterdata_TitleFilter_05 - description: Verify that the system successfully filters titles by isActive status in English (smoke test) + description: Verify that the system returns an error when filtering titles with an unsupported FilterType (between)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleFilter/TitleFilter.yml` around lines 102 - 127, The YAML entry uses a duplicate key MasterData_TitleFilter_isActive__eng_smoke and a misleading description; rename the key to reflect the negative test (e.g., MasterData_TitleFilter_invalidFilterType__eng_TC05 or a name containing TC_Masterdata_TitleFilter_05) and update the description to state this is a negative test that verifies an unsupported filter type (filtering titleName with type "between" returns KER-MSD-324), and ensure the uniqueIdentifier (TC_Masterdata_TitleFilter_05) remains consistent with the new key; locate the entry by its current key, uniqueIdentifier, endPoint (/v1/masterdata/title/filtervalues) and the input payload (columnName: "titleName", type: "between") to make the edits.
🟡 Minor comments (23)
api-test/src/main/resources/masterdata/UpdateIdSchema/UpdateIdSchema.yml-27-27 (1)
27-27:⚠️ Potential issue | 🟡 MinorDescription wording doesn't match the actual error condition.
The description says "already exists" but the expected error (
KER-SCH-009) and its message are"Schema already published". Since this PR's goal is to improve clarity, aligning the description with the actual error condition avoids ambiguity (an "already exists" phrasing could be confused with a duplicate-record/creation error rather than a publish-state error).✏️ Proposed fix
- description: Verify that the system returns an error when updating a record with an IdSchema that already exists + description: Verify that the system returns an error when updating a record with an IdSchema that has already been published🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateIdSchema/UpdateIdSchema.yml` at line 27, Update the test description in UpdateIdSchema.yml so it reflects the publish-state error rather than a generic "already exists" condition: replace the current description with a phrase like "Verify that the system returns an error when updating a record with an IdSchema that is already published" to match the expected error code KER-SCH-009 and message "Schema already published" referenced by the test.api-test/src/main/resources/masterdata/RejectionReason/RejectionReason.yml-5-5 (1)
5-5:⚠️ Potential issue | 🟡 MinorDescription is inaccurate — it describes a fetch but the test performs a POST/create.
The updated description says "fetches all rejection reasons", yet:
restMethodispost, notget.- The
inputpayload contains a full resource body (code,name,description,isActive,langCode,requesttime), which is characteristic of a create operation.- The
outputasserts the createdcode, not a list.The previous description ("Create rejection reason with valid details") was factually aligned with the test's behaviour. A sibling directory (
GetPacketRejectionReason/) appears to own the actual fetch test; the new wording looks like it was inadvertently borrowed from that test.The description should remain true to what the test exercises:
✏️ Proposed fix
- description: Verify that the system successfully fetches all rejection reasons when all input parameters are valid + description: Verify that the system successfully creates a rejection reason when all input parameters are valid🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/RejectionReason/RejectionReason.yml` at line 5, The description is incorrect for the test in RejectionReason.yml: the test uses restMethod: post, sends a full resource input (code, name, description, isActive, langCode, requesttime) and asserts the created code, so update the description to reflect a create operation (e.g., "Create rejection reason with valid details" or similar) rather than "fetches all rejection reasons"; reference the restMethod, input payload fields and the output assertion to ensure the wording matches the POST/create behavior.api-test/src/main/resources/masterdata/UpdateDeviceType/UpdateDeviceType.yml-20-20 (1)
20-20:⚠️ Potential issue | 🟡 MinorDescription is inaccurate —
isActive=falseis a valid parameter, not an invalid one.The phrase "invalid status parameter" implies the value
falseis malformed or unrecognised. In reality,falseis a perfectly valid boolean; the test fails due to a business constraint (KER-MSD-055: existing mappings must be removed before deactivating). The wording will mislead a reader into thinking the parameter format is wrong rather than the business rule being violated.✏️ Suggested rewording
- description: Verify that the system returns an error when updating a device type with an invalid status parameter + description: Verify that the system returns an error when attempting to deactivate a device type that has existing mappings🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateDeviceType/UpdateDeviceType.yml` at line 20, Update the test description to reflect that isActive=false is a valid boolean but deactivation is blocked by a business rule (KER-MSD-055) requiring existing mappings to be removed first; change the sentence referencing "invalid status parameter" to something like "Verify the system returns an error when attempting to deactivate a device type (isActive=false) while existing mappings exist (business rule KER-MSD-055)". Ensure the new wording appears where the current description value is set for UpdateDeviceType.yml so readers understand this is a business-constraint failure, not a malformed parameter.api-test/src/main/resources/masterdata/ValidDocument/CreateValidDocument.yml-24-24 (1)
24-24:⚠️ Potential issue | 🟡 MinorDescriptions use "missing" but the tests send blank/empty values — inaccurate wording.
Both TC_02 and TC_03 supply the field as an empty string (
""), meaning the key is present in the payload; it is simply blank. "Missing" implies the key is absent entirely. Notably, the expected error messages themselves say "Should not be blank", making the mismatch directly visible in the same test case.Since this PR's explicit goal is improving description clarity, consider correcting to "blank" or "empty":
✏️ Proposed fix
- description: Verify that the system returns an error when creating a document with the docTypeCode parameter missing + description: Verify that the system returns an error when creating a document with the docTypeCode parameter blank/empty- description: Verify that the system returns an error when creating a document with the docCategoryCode parameter missing + description: Verify that the system returns an error when creating a document with the docCategoryCode parameter blank/emptyAlso applies to: 47-47
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocument/CreateValidDocument.yml` at line 24, Update the test descriptions to accurately reflect that the docTypeCode field is present but blank, not absent: change wording in the CreateValidDocument.yml test cases TC_02 and TC_03 (the descriptions currently saying "missing") to "blank" or "empty" (e.g., "docTypeCode is blank/empty") so they match the payloads and the expected error messages ("Should not be blank").api-test/src/main/resources/masterdata/ValidDocumentFilter/ValidDocumentFilter.yml-88-88 (1)
88-88:⚠️ Potential issue | 🟡 Minor
Blank_FilterTypedescription is imprecise and would be ambiguous alongsideInValid_FilterType.The test sends
"type": ""(an empty string), so the description should say "blank" or "empty" rather than just "invalid". Using "invalid" here produces a description that is effectively identical toMasterData_ValidDocumentFilter_InValid_FilterType(TC_03), making the two cases indistinguishable by their descriptions alone.✏️ Suggested fix
- description: Verify that the system returns an error when filtering documents with an invalid FilterType parameter + description: Verify that the system returns an error when filtering documents with a blank (empty) FilterType parameter🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocumentFilter/ValidDocumentFilter.yml` at line 88, Update the description for the Blank_FilterType test case to clearly state that the FilterType is empty/blank rather than "invalid" so it is distinguishable from MasterData_ValidDocumentFilter_InValid_FilterType (TC_03); locate the Blank_FilterType entry (reference symbol: Blank_FilterType) in ValidDocumentFilter.yml and change the description to something like "Verify that the system returns an error when filtering documents with a blank/empty FilterType parameter" to reflect the actual test input.api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml-58-58 (1)
58-58:⚠️ Potential issue | 🟡 MinorDescription inaccurate: "missing" vs. empty string.
The description says "with the regCenterId parameter missing", but the actual input sends
"regCenterId": ""— an explicitly present key with an empty string value. A genuinely missing parameter would omit the key from the payload entirely. Calling it "missing" misrepresents the test condition.✏️ Proposed fix
- description: Verify that the system returns an error when updating a user-center mapping with the regCenterId parameter missing + description: Verify that the system returns an error when updating a user-center mapping with an empty regCenterId parameter🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UserCenterMapping/UserCenterMapping.yml` at line 58, Update the test case description to accurately reflect the payload: change "with the regCenterId parameter missing" to indicate that regCenterId is present but empty (e.g., "with the regCenterId provided as an empty string"); ensure the description in UserCenterMapping.yml matches the actual request body used by the test rather than implying the key is omitted.api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml-25-25 (1)
25-25:⚠️ Potential issue | 🟡 MinorDescriptions for TC_02, TC_04, and TC_05 incorrectly say "creating" for an update (PUT) operation.
All three updated descriptions use the word "creating" despite the test cases exercising
restMethod: putagainst the update endpoint/v1/masterdata/blocklistedwords/details. This contradicts the PR's stated goal of improving clarity.✏️ Proposed fixes
Line 25:
- description: Verify that the system returns an error when creating a blocklisted word with length exceeding 128 characters + description: Verify that the system returns an error when updating a blocklisted word with word length exceeding 128 charactersLine 73:
- description: Verify that the system returns an error when creating a blocklisted word with Description exceeding 256 characters + description: Verify that the system returns an error when updating a blocklisted word with description exceeding 256 charactersLine 97:
- description: Verify that the system returns an error when creating a blocklisted word with the Word parameter empty + description: Verify that the system returns an error when updating a blocklisted word with the Word parameter emptyAlso applies to: 73-73, 97-97
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateBlockListedWordDetails/UpdateBlockListedWordDetails.yml` at line 25, The descriptions for test cases TC_02, TC_04, and TC_05 incorrectly say "creating" even though they exercise restMethod: put against the update endpoint /v1/masterdata/blocklistedwords/details; open the YAML entries for TC_02, TC_04, and TC_05 and replace "creating" with "updating" (or rephrase to "updating a blocklisted word" / "update operation") so the description accurately reflects the PUT operation and the /v1/masterdata/blocklistedwords/details endpoint.api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml-81-81 (1)
81-81:⚠️ Potential issue | 🟡 MinorTwo minor description inaccuracies.
Line 81 — Trailing period: This description ends with a
.while all other ten descriptions in the file do not. Minor punctuation inconsistency.Line 157 — Wrong parameter name: The description says "sortFieldType parameter" but the actual JSON field tested is
sortType("sortType": ""). The non-existent aliassortFieldTypeis confusing.✏️ Proposed fixes
- description: Verify that the system returns an error or handles gracefully when an invalid sort field is provided during machine type search. + description: Verify that the system returns an error or handles gracefully when an invalid sort field is provided during machine type search- description: Verify that the system returns an error or handles gracefully when the sortFieldType parameter is empty during machine type search + description: Verify that the system returns an error or handles gracefully when the sortType parameter is empty during machine type searchAlso applies to: 157-157
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml` at line 81, Update the YAML descriptions to match the actual payload and formatting: remove the trailing period from the description that currently reads "Verify that the system returns an error or handles gracefully when an invalid sort field is provided during machine type search." so it matches other entries, and correct the parameter name in the other description that refers to the non-existent "sortFieldType" to use the real JSON field name "sortType" (the test payload uses "sortType": ""), ensuring both descriptions reference the "description" key and the "sortType" parameter consistently.api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml-5-5 (1)
5-5:⚠️ Potential issue | 🟡 MinorDescription references the wrong field —
code, notName.The filter in the test input uses
"columnName": "code"with"type": "equals", so the description should refer to the code parameter, not "Name". As written, this misleads anyone reading the test metadata about what is actually being matched.✏️ Proposed fix
- description: Verify that the system successfully returns machine type records that exactly match the Name parameter in English during a search + description: Verify that the system successfully returns machine type records that exactly match the code parameter in English during a search🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/MachineTypeSearch/MachineTypeSearch.yml` at line 5, Update the YAML test description to reference the correct field: change the description that mentions "Name" to refer to the "code" parameter since the test filter uses "columnName": "code" with "type": "equals"; locate the description field in MachineTypeSearch.yml and replace the wording so it accurately states that the test verifies exact matches on the code parameter in English.api-test/src/main/resources/masterdata/ResumePacketWorkflow/ResumePacket.yml-4-4 (1)
4-4:⚠️ Potential issue | 🟡 MinorDuplicate
uniqueIdentifierbreaks test traceability.Both
MasterData_ResumePacketWorkflow_inValid_workFlowIdandMasterData_ResumePacketWorkflow_inValid_requesttimeshareTC_Masterdata_ResumePacketWorkflow_01. Since this PR's intent is to improve test clarity, the duplicate ID is directly at odds with that goal — test reporting systems will conflate results for these two distinct cases. The second test case should get a unique identifier (e.g.,TC_Masterdata_ResumePacketWorkflow_02).🔧 Proposed fix
MasterData_ResumePacketWorkflow_inValid_requesttime: endPoint: /v1/masterdata/packet/resume - uniqueIdentifier: TC_Masterdata_ResumePacketWorkflow_01 + uniqueIdentifier: TC_Masterdata_ResumePacketWorkflow_02Also applies to: 24-24
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ResumePacketWorkflow/ResumePacket.yml` at line 4, The duplicate uniqueIdentifier value should be changed so tests don't conflate results: locate the YAML entry with uniqueIdentifier for the test cases MasterData_ResumePacketWorkflow_inValid_workFlowId and MasterData_ResumePacketWorkflow_inValid_requesttime and update the second instance from TC_Masterdata_ResumePacketWorkflow_01 to a new unique value (e.g., TC_Masterdata_ResumePacketWorkflow_02); ensure the uniqueIdentifier field is updated only for the second test case so both tests have distinct IDs.api-test/src/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml-5-8 (1)
5-8:⚠️ Potential issue | 🟡 MinorDescription says "fetches" but the REST method is
postwith a create-shaped payload.The updated description reads "Verify that the system successfully fetches all packet rejection reason categories…", yet
restMethodispost(line 8) and the input body containscode,name,description,langCode,isActive, andrequesttime— all fields consistent with a create operation. The previous description ("Create packer rejection reason category with valid data") was semantically accurate. Changing it to "fetches" misrepresents what the test actually exercises.✏️ Suggested correction
- description: Verify that the system successfully fetches all packet rejection reason categories when all input parameters are valid + description: Verify that the system successfully creates a packet rejection reason category when all input parameters are valid🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml` around lines 5 - 8, The description text is inconsistent with the REST operation: restMethod is set to post and the payload contains create fields (code, name, description, langCode, isActive, requesttime), so update the description to reflect a create test (e.g., "Create packet rejection reason category with valid data") or otherwise align it with the intended operation; ensure the YAML keys description and restMethod remain consistent with the request body and templateFields (langCode).api-test/src/main/resources/masterdata/ValidDocumentSearch/ValidDocumentSearch.yml-119-119 (1)
119-119:⚠️ Potential issue | 🟡 Minor"Negative value" is a misleading characterisation for TC_05, TC_06, and TC_07.
All three descriptions (lines 119, 150, 182) use the phrase "negative … value", which implies a negative numeric input. However, the actual invalid inputs are:
Test Field Invalid Input Error TC_05 ( _FilterType_neg)type"asdf"(unknown string)KER-MSD-318 TC_06 ( _SortType_neg)sortType"asdf"(unsupported string)"Sort type asdf is not supported" TC_07 ( _SortField_neg)sortField"createddDateTime"(invalid field name)"Invalid sort field createddDateTime" The
_negsuffix in the test case names is a standard testing convention for negative test scenarios, not a literal negative numeric value. The word "negative" in the descriptions misrepresents the nature of the invalid inputs.✏️ Proposed fix
- description: Verify that the system returns an error when searching documents with a negative FilterType value + description: Verify that the system returns an error when searching documents with an invalid (unrecognized) FilterType value- description: Verify that the system returns an error when searching documents with a negative SortType value + description: Verify that the system returns an error when searching documents with an unsupported SortType value- description: Verify that the system returns an error when searching documents with a negative SortField value + description: Verify that the system returns an error when searching documents with an invalid SortField valueAlso applies to: 150-150, 182-182
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocumentSearch/ValidDocumentSearch.yml` at line 119, Update the three test descriptions to remove the misleading phrase "negative … value" and instead describe the actual invalid string inputs for the named tests: for TC_05 (_FilterType_neg) state that `type` is an unknown string (e.g., "asdf") causing KER-MSD-318, for TC_06 (_SortType_neg) state that `sortType` is an unsupported string (e.g., "asdf") producing "Sort type asdf is not supported", and for TC_07 (_SortField_neg) state that `sortField` is an invalid field name (e.g., "createddDateTime") producing "Invalid sort field createddDateTime"; change the description fields for those test cases accordingly so they accurately reflect the invalid string inputs rather than implying a negative numeric value.api-test/src/main/resources/masterdata/ValidDocumentSearch/ValidDocumentSearch.yml-215-215 (1)
215-215:⚠️ Potential issue | 🟡 MinorDescription contradicts the actual expected outcome — this is a negative test, not a positive one.
The description says the system "successfully searches documents" and labels it a "positive test", but the test's
outputTemplateismasterdata/errorand the expected output is error codeKER-MSD-314with the message"Missing sort field or sort type values". A blanksortFieldcauses a failure, not a success.✏️ Proposed fix
- description: Verify that the system successfully searches documents when the SortField parameter is left blank (positive test) + description: Verify that the system returns an error when searching documents with a blank SortField value🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ValidDocumentSearch/ValidDocumentSearch.yml` at line 215, Update the test description to reflect that this is a negative test expecting an error: change the description field (currently "Verify that the system successfully searches documents when the SortField parameter is left blank (positive test)") to state that leaving sortField blank should fail and return error KER-MSD-314 with outputTemplate masterdata/error (e.g., "Verify that leaving sortField blank returns error KER-MSD-314 'Missing sort field or sort type values' (negative test)").api-test/src/main/resources/masterdata/Machine/UpdateMachine.yml-207-207 (1)
207-207:⚠️ Potential issue | 🟡 MinorDescription is misleading — expected error is a zone authorization failure, not a MAC address validation error.
The updated description states the test verifies behavior "when the MAC address is blank," implying a validation failure on
macAddress. However, the expected output is error codeKER-MSD-255with message"Admin not authorized to access this Machine for this Zone"— a zone authorization error, not a field-validation error. A reader relying on this description to understand test intent will be misled.The description should reflect what the system actually returns, e.g.:
✏️ Suggested description correction
- description: Verify that the system returns an error when the MAC address is blank during machine update + description: Verify that the system returns a zone authorization error when attempting to update a machine with a blank MAC address🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/Machine/UpdateMachine.yml` at line 207, Update the test case description in UpdateMachine.yml to accurately reflect that the test asserts a zone authorization failure rather than a MAC address validation error: change the description to state the system returns error code KER-MSD-255 with message "Admin not authorized to access this Machine for this Zone" when attempting to update a machine outside the admin's authorized zone, so the description matches the expected response in the test case.api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml-171-171 (1)
171-171:⚠️ Potential issue | 🟡 MinorTC_05 description inaccurately claims sorting by
isActive.The description reads "filtering or sorting by the isActive column," but the
sortblock usessortField: "name", notisActive. Only the filter is onisActive.✏️ Suggested correction
- description: Verify that the system successfully retrieves machine specifications when filtering or sorting by the isActive column + description: Verify that the system successfully retrieves machine specifications when filtering by the isActive column🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml` at line 171, The TC_05 description inaccurately mentions sorting by isActive while the spec uses sortField: "name" and only filters on isActive; update the description in the SearchMachineSpec.yml for TC_05 to accurately reflect the behavior (e.g., "Verify that the system successfully retrieves machine specifications when filtering by the isActive column") or, if sorting by isActive was intended, change the sort block's sortField from "name" to "isActive" so description and spec match; refer to the TC_05 description field and the sort block (sortField: "name") and the isActive filter to implement the correct change.api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml-240-240 (1)
240-240:⚠️ Potential issue | 🟡 Minor"negative … value" is incorrect terminology in TC_08, TC_09, TC_10, and TC_13
All four descriptions carry the phrase "with a negative X value", but none of the test inputs use a negative numeric value:
TC Field Invalid value used Actual error TC_08 (line 240) FilterType "between"Unsupported filter type TC_09 (line 276) SortType "adgfh"Unsupported sort type TC_10 (line 312) SortField "lang_code"Invalid sort field name TC_13 (line 420) RequestTime "2019-7-3T05:22:35.845"Invalid format "Negative" correctly applies to TC_06 and TC_07 (where the values are literally
-1). For these four cases, "invalid" or a more specific qualifier is accurate.✏️ Proposed fixes
# TC_08 (line 240) - description: Verify that the system returns an error when searching titles with a negative FilterType value + description: Verify that the system returns an error when searching titles with an unsupported FilterType value # TC_09 (line 276) - description: Verify that the system returns an error when searching titles with a negative SortType value + description: Verify that the system returns an error when searching titles with an unsupported SortType value # TC_10 (line 312) - description: Verify that the system returns an error when searching titles with a negative SortField value + description: Verify that the system returns an error when searching titles with an invalid SortField value # TC_13 (line 420) - description: Verify that the system returns an error when searching titles with a negative RequestTime value + description: Verify that the system returns an error when searching titles with an invalid RequestTime formatAlso applies to: 276-276, 312-312, 420-420
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml` at line 240, Update the misleading "negative ... value" wording in the TitleSearch.yml test descriptions for TC_08, TC_09, TC_10, and TC_13: locate the descriptions for test cases TC_08 (FilterType), TC_09 (SortType), TC_10 (SortField) and TC_13 (RequestTime) and replace "negative" with "invalid" or a more specific qualifier (e.g., "unsupported" for FilterType/SortType, "invalid field name" for SortField, "invalid format" for RequestTime) so the description matches the actual invalid test inputs used.api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml-349-349 (1)
349-349:⚠️ Potential issue | 🟡 MinorDescription contradicts the expected output — TC_11 expects an error, not a successful search
The new description calls this a "positive test" where the system "successfully searches titles", but the expected output is the error response
KER-MSD-314: Missing sort field or sort type values. The blanksortFieldis the invalid condition under test; the outcome is an error, not a success.✏️ Proposed fix
- description: Verify that the system successfully searches titles when the SortField parameter is left blank (positive test) + description: Verify that the system returns an error when searching titles with a blank SortField parameter🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml` at line 349, The description for TC_11 is wrong: it calls the case a "positive test" and says the system "successfully searches titles" while the expected output is an error (`KER-MSD-314: Missing sort field or sort type values`); update the description in TitleSearch.yml for TC_11 to state that leaving sortField blank is an invalid condition and that the system should return the KER-MSD-314 error (remove "positive test" language and explicitly mention the expected error response).api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml-137-137 (1)
137-137:⚠️ Potential issue | 🟡 MinorDescription incorrectly states the test expects an error, and misuses "negative"
Two problems with
TC_Masterdata_TitleSearch_05:
- The expected output is
"data": []— an empty result set — not an"errors": [...]response. Saying "returns an error" is factually wrong.- "negative Name value" is inaccurate; the filter value
"Language"is simply a non-existent title name, not a negative value.✏️ Proposed fix
- description: Verify that the system returns an error when searching titles with a negative Name value + description: Verify that the system returns an empty result when searching titles with a non-existent Name value🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleSearch/TitleSearch.yml` at line 137, Update the description for test case TC_Masterdata_TitleSearch_05 to correctly state that the request should return an empty result set rather than an error and to clarify that the filter uses a non-existent title name ("Language") rather than a "negative" value; specifically replace the sentence "Verify that the system returns an error when searching titles with a negative Name value" with something like "Verify that the system returns an empty result (\"data\": []) when searching titles using a non-existent Name value ('Language')."api-test/src/main/resources/masterdata/LocationData/CreateLocationData.yml-136-136 (1)
136-136:⚠️ Potential issue | 🟡 MinorDescription does not accurately reflect the test input.
The updated description reads:
"Verify that the system returns an error when the hierarchy level does not match the location hierarchy combination"
However, the input's
hierarchyLevelis"363g3vf@636336gg"— a malformed, non-numeric string. This is an invalid format error, not a semantic mismatch between a valid hierarchy level and a valid location hierarchy combination. The "does not match" phrasing implies both sides are individually valid but conflict, which is misleading.Consider a more precise description such as:
"Verify that the system returns an error when the hierarchy level contains an invalid (non-numeric) format during location data creation"
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/LocationData/CreateLocationData.yml` at line 136, Update the test description in CreateLocationData.yml to accurately reflect the input error: the hierarchyLevel value "363g3vf@636336gg" is a malformed non-numeric format, not a semantic mismatch; change the description field (the YAML key "description" in CreateLocationData.yml) to something like "Verify that the system returns an error when the hierarchy level contains an invalid (non-numeric) format during location data creation" so it matches the test input.api-test/src/main/resources/masterdata/TitleFilter/TitleFilter.yml-58-58 (1)
58-58:⚠️ Potential issue | 🟡 MinorDescription uses "negative" where "invalid format" is the correct term.
The requesttime
"2019-7-3T05:22:35.845"is not a negative value — it is a malformed ISO-8601 timestamp (missing leading zeros in month/day). The returned error "Invalid Format in field : requesttime" confirms this. Saying "negative" could mislead readers into thinking the test exercises a negative numeric timestamp.✏️ Proposed fix
- description: Verify that the system returns an error when filtering titles with a negative RequestTime value + description: Verify that the system returns an error when filtering titles with an invalid (malformed) RequestTime format🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/TitleFilter/TitleFilter.yml` at line 58, Change the test case description that currently says "negative" to state "invalid format" to accurately reflect the failure mode; update the description for the TitleFilter test (the description field in TitleFilter.yml) to mention the malformed ISO-8601 requesttime value ("2019-7-3T05:22:35.845") and that it should return an "Invalid Format in field : requesttime" error so the wording matches the actual validation being exercised.api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml-71-71 (1)
71-71:⚠️ Potential issue | 🟡 MinorTC_03, TC_04: Descriptions say "filterValue is null" but the input sends an empty string
"".Both test cases pass
"value": ""in the request body. Describing this as "null" is imprecise; it is an empty string. Since this PR's stated goal is to improve clarity, using the correct term is important.✏️ Proposed fix
# TC_03 - description: Verify that the system returns an error when columnName is Name, langCode is eng, filterType is equals, and filterValue is null + description: Verify that the system returns an error when columnName is Name, langCode is eng, filterType is equals, and filterValue is an empty string # TC_04 - description: Verify that the system returns an error when columnName is Name, langCode is eng, filterType is startsWith, and filterValue is null + description: Verify that the system returns an error when columnName is Name, langCode is eng, filterType is startsWith, and filterValue is an empty stringAlso applies to: 107-107
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml` at line 71, Update the test case descriptions for TC_03 and TC_04 (and the other occurrence noted) to accurately state that filterValue is an empty string rather than null; locate the YAML entries for TC_03 and TC_04 in SearchTemplateDetails.yml and replace wording like "filterValue is null" with "filterValue is an empty string (\"\")" so the description matches the request body which uses "value": "".api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml-143-143 (1)
143-143:⚠️ Potential issue | 🟡 MinorTC_05, TC_06, TC_07: Descriptions say "returns an error" but the tests expect a successful 0-result response.
All three test cases (
filterValue_invalidvariants for startsWith, equals, and contains) setcheckErrorsOnlyInResponse: trueand assert"totalRecord": "0"via the success output template. The system is expected to process the request successfully and return zero results — not return an error. The new descriptions introduce a misleading characterisation.✏️ Proposed fix (apply to all three cases)
# TC_05 - description: Verify that the system returns an error for invalid filterValue when columnName is Name, langCode is eng, and filterType is startsWith + description: Verify that the system returns an empty result set (totalRecord 0) when a non-existent filterValue is provided and columnName is Name, langCode is eng, filterType is startsWith # TC_06 - description: Verify that the system returns an error for invalid filterValue when columnName is Name, langCode is eng, and filterType is equals + description: Verify that the system returns an empty result set (totalRecord 0) when a non-existent filterValue is provided and columnName is Name, langCode is eng, filterType is equals # TC_07 - description: Verify that the system returns an error for invalid filterValue when columnName is Name, langCode is eng, and filterType is contains + description: Verify that the system returns an empty result set (totalRecord 0) when a non-existent filterValue is provided and columnName is Name, langCode is eng, filterType is containsAlso applies to: 175-175, 207-207
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchTemplateDetails/SearchTemplateDetails.yml` at line 143, Update the description fields for the three test cases TC_05, TC_06, and TC_07 (the cases named with filterValue_invalid for filterType startsWith, equals, and contains) so they reflect that the API should succeed and return zero results instead of "returns an error"; specifically edit the YAML description entries to state that the system returns a successful response with totalRecord = "0" (these cases already set checkErrorsOnlyInResponse: true and use the success output template asserting "totalRecord": "0"). Ensure the description text mentions the columnName (Name) and langCode (eng) and that the filter value is invalid and thus yields no matches.api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml-207-207 (1)
207-207:⚠️ Potential issue | 🟡 MinorDescription inaccurately states "returns an error" — the test expects 0 results, not an error.
MasterData_SearchDocCategories_inValid_filter_valueusesoutputTemplate: masterdata/SearchDocCategories/searchDocCategoriesResult(the success template) and asserts"totalRecord": "0". No error response is expected. The description should reflect that the system returns an empty result set, not an error.✏️ Proposed fix
- description: Verify that the system returns an error when an invalid filter value is provided while searching document categories + description: Verify that the system returns an empty result set (totalRecord 0) when a non-existent filter value is provided while searching document categories🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml` at line 207, Update the test description for MasterData_SearchDocCategories_inValid_filter_value to accurately state that an invalid filter value yields an empty result set (totalRecord: 0) rather than an error; change the description text that currently says "returns an error" to something like "returns 0 results / empty result set when an invalid filter value is provided", leaving outputTemplate: masterdata/SearchDocCategories/searchDocCategoriesResult and the existing assertion intact.
🧹 Nitpick comments (4)
api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml (1)
21-21: Nitpick: lowercase "word" for consistent prose casing."invalid Word parameter" —
Wordis capitalized mid-sentence without apparent reason. It should be lowercase to match standard prose conventions.✏️ Suggested fix
- description: Verify that the system returns an error when updating the status of a blocklisted word with an invalid Word parameter + description: Verify that the system returns an error when updating the status of a blocklisted word with an invalid word parameter🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/UpdateBlockListedWordStatus/UpdateBlockListedWordStatus.yml` at line 21, Update the description value for the UpdateBlockListedWordStatus test case by changing the mid-sentence capitalized "Word" to lowercase "word" (update the description key: "Verify that the system returns an error when updating the status of a blocklisted word with an invalid Word parameter" → use "invalid word parameter") so prose casing is consistent.api-test/src/main/resources/masterdata/ResumePacketWorkflow/ResumePacket.yml (1)
30-34:MasterData_ResumePacketWorkflow_inValid_requesttimealso submits an invalidworkflowId.The test is scoped to validating
requesttime, butworkflowId: "sfgbvafb"is the same invalid value from the first test case. The expected errorKER-MSD-999is only returned if requesttime validation fires before workflowId validation. If validation order changes, this test will silently break for the wrong reason. Consider using a validworkflowId(or one that at least doesn't triggerRPR-WAA-003) to isolate the requesttime assertion.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/ResumePacketWorkflow/ResumePacket.yml` around lines 30 - 34, The test MasterData_ResumePacketWorkflow_inValid_requesttime is submitting an invalid workflowId ("sfgbvafb") which can cause the test to fail for the wrong reason (RPR-WAA-003) instead of the intended requesttime validation (KER-MSD-999); update the YAML test input so workflowId is a valid/non-triggering value (e.g., a known-good workflowId or a properly formatted UUID) and leave requesttime as the invalid value being tested so only requesttime validation fires.api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml (1)
572-572: Description usespageSizebut the request field ispageFetch."an invalid pageSize is provided" — the actual input field driving this test is
pageFetch: -1. Using the correct field name keeps descriptions unambiguous when cross-referencing against the API contract.✏️ Suggested correction
- description: Verify that the system returns an error when an invalid pageSize is provided while searching machine specifications + description: Verify that the system returns an error when an invalid pageFetch value is provided while searching machine specifications🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchMachineSpec/SearchMachineSpec.yml` at line 572, Update the description string in the SearchMachineSpec YAML test so it references the actual request field name "pageFetch" instead of "pageSize" (i.e., change the description that currently reads "an invalid pageSize is provided" to mention "an invalid pageFetch is provided") so the test description matches the request payload used by this spec.api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml (1)
46-46: Extraneous leading space in description value.Line 46 has two spaces after the colon (
description: Verify …) while all other test cases use a single space. Minor consistency nit.✏️ Proposed fix
- description: Verify that the system successfully fetches document categories sorted by code when a valid sort parameter is provided + description: Verify that the system successfully fetches document categories sorted by code when a valid sort parameter is provided🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@api-test/src/main/resources/masterdata/SearchDocCategories/SearchDocCategories.yml` at line 46, The description value in the SearchDocCategories.yml test case has an extra leading space after the colon ("description: Verify..."); update the YAML entry for the description key in SearchDocCategories.yml so it uses a single space after the colon (e.g., "description: Verify that...") to match the formatting of the other test cases.
...rc/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml
Outdated
Show resolved
Hide resolved
...rc/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml
Outdated
Show resolved
Hide resolved
prathmeshj12
left a comment
prathmeshj12
left a comment
There was a problem hiding this comment.
Please fix the code rabbit review comments
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@api-test/src/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml`:
- Line 5: The test description in PacketRejectionReasonCategory.yml is
inconsistent with restMethod: post; update the description field to reflect a
create operation (e.g., "Verify that the system successfully creates a packet
rejection reason category when all input parameters are valid") so the
description matches the HTTP verb and intent; locate the description entry in
PacketRejectionReasonCategory.yml associated with restMethod: post and replace
the current "fetches" wording accordingly.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
api-test/src/main/resources/masterdata/GetHolidaysMissingIds/GetHolidaysMissingIds.ymlapi-test/src/main/resources/masterdata/GetTemplateFileFormat/GetTemplateFileFormat.ymlapi-test/src/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- api-test/src/main/resources/masterdata/GetTemplateFileFormat/GetTemplateFileFormat.yml
- api-test/src/main/resources/masterdata/GetHolidaysMissingIds/GetHolidaysMissingIds.yml
...rc/main/resources/masterdata/PacketRejectionReasonCategory/PacketRejectionReasonCategory.yml
Show resolved
Hide resolved
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
|
Solve all code rabbit comments |
… clarity and readability Signed-off-by: Famuda1234 <famuda.m@cyberpwn.com>
3 participants
… clarity
Summary by CodeRabbit
Tests
Chores