feat: TCS, Simulation and Masking unit test cases#331
Conversation
…askingInDB functions Co-authored-by: Copilot <copilot@github.com>
…ions Co-authored-by: Copilot <copilot@github.com>
…sByStatus functions Co-authored-by: Copilot <copilot@github.com>
…nd default handling in TCS Config Repository Co-authored-by: Copilot <copilot@github.com>
📝 WalkthroughWalkthroughThis PR extends test coverage across multiple repository and service modules, introduces new test files for rule-flow and simulation-logs repositories, and removes the ChangesTCS Config Service Refactoring
Masking Service & Repository Tests
Core Repository Test Expansion
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
__tests__/unit/tcs-config.logic.service.test.ts (3)
445-475: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winTest has no assertions — only verifies absence of throw.
handleAddMappingreturns a value intoresultbut nothing is asserted on it (or on the repository call). The same gap exists in'should add function with default empty arrays'at lines 676-705. As written, these tests pass as long as the call doesn't throw, which doesn't validate the "add to existing mappings" / "default empty arrays" intent.✅ Suggested assertions for the existing-mappings test
const result = await tcsConfigService.handleAddMapping(1, mockTenantId, newMapping as any); + + expect(tcsConfigRepository.updateConfig).toHaveBeenCalledWith( + 1, + mockTenantId, + { mapping: [existingMapping, { ...newMapping, source: ['newField'] }] }, + ); + expect(result.mapping).toHaveLength(2); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@__tests__/unit/tcs-config.logic.service.test.ts` around lines 445 - 475, The test "should add mapping to existing mappings" currently only calls tcsConfigService.handleAddMapping and doesn't assert behavior; update the test to assert the returned result equals the mockUpdatedConfig and verify tcsConfigRepository.findConfigById and tcsConfigRepository.updateConfig were called with the expected arguments (id, tenant id and the updated mapping payload where newMapping.source has been normalized to an array). Do the same for the related "should add function with default empty arrays" test: assert the returned value, and verify repository calls include the default-empty-array normalization for function properties so the tests validate the intended additions rather than merely ensuring no exception was thrown.
271-277:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winStale 4th argument to
handleUpdateConfig.The service signature is now
handleUpdateConfig(id, tenantId, updates)(3 args) — theupdatedAtparameter was removed in this PR. The trailing'2026-04-07T10:00:00.000Z'here is a leftover that no longer maps to any parameter and will either be a TS error or silently ignored at runtime.✂️ Suggested fix
- await expect(tcsConfigService.handleUpdateConfig(1, mockTenantId, { msgFam: 'Updated' }, '2026-04-07T10:00:00.000Z')).rejects.toThrow( - 'Failed to update configuration', - ); + await expect(tcsConfigService.handleUpdateConfig(1, mockTenantId, { msgFam: 'Updated' })).rejects.toThrow( + 'Failed to update configuration', + );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@__tests__/unit/tcs-config.logic.service.test.ts` around lines 271 - 277, The test calls tcsConfigService.handleUpdateConfig with a stale 4th argument (timestamp) but the service signature is handleUpdateConfig(id, tenantId, updates); remove the trailing '2026-04-07T10:00:00.000Z' from the test invocation so it calls handleUpdateConfig(1, mockTenantId, { msgFam: 'Updated' }) and adjust any related expectations/mocks referencing the old 4th param accordingly.
600-642:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDuplicate test cases — drop the second copy.
The test
'should set mapping to empty array when last mapping is removed'is defined twice with identical bodies (lines 600-620 and 622-642). The same duplication exists inhandleRemoveFunctionfor'should set functions to empty array when last function is removed'at lines 799-819 and 821-841. Remove one copy of each pair.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@__tests__/unit/tcs-config.logic.service.test.ts` around lines 600 - 642, Remove the duplicated test blocks that repeat the same assertions: delete one of the two identical "should set mapping to empty array when last mapping is removed" tests that exercise tcsConfigService.handleRemoveMapping (the duplicated test bodies that mock tcsConfigRepository.findConfigById and updateConfig and assert updateConfig called with { mapping: [] }), and likewise delete one of the two identical "should set functions to empty array when last function is removed" tests that exercise tcsConfigService.handleRemoveFunction; keep a single instance of each test case so only one test per behavior remains.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@__tests__/unit/repositories/masking.repository.test.ts`:
- Around line 238-245: The test uses expect.objectContaining with duplicate
"text" keys when asserting calls to mockHandlePostExecuteSqlStatement (e.g.
checking 'INSERT INTO trs_masking' and 'RETURNING id'), which silently drops
earlier text assertions; change the assertion to capture the actual argument
passed to mockHandlePostExecuteSqlStatement and use separate toContain (or
expect.stringContaining) assertions against the capturedArg.text for each
fragment (e.g., assert capturedArg.text contains 'INSERT INTO trs_masking' and
capturedArg.text contains 'RETURNING id' and values equals
['DEFAULT','pain.001.001.11','11']), and apply the same fix for the other block
that checks 'UPDATE trs_masking' / 'SET' so each SQL fragment is asserted
separately rather than using duplicate "text" keys in expect.objectContaining.
In `@__tests__/unit/repositories/rule-flow.repository.test.ts`:
- Around line 345-355: The test is incorrectly using multiple `text` keys inside
expect.objectContaining which only keeps the last one; instead capture the
actual SQL argument passed to mockHandlePostExecuteSqlStatement (e.g., const
sqlArg = mockHandlePostExecuteSqlStatement.mock.calls[0][0]) in the test for
findRuleFlowFromDB and then assert each SQL fragment separately with
expect(sqlArg.text).toContain('SELECT *'), expect(sqlArg.text).toContain('FROM
trs_rule_flow'), expect(sqlArg.text).toContain('WHERE rule_id = $1 AND tenant_id
= $2') and assert values separately (expect(sqlArg.values).toEqual([mockRuleId,
mockTenantId])); apply the same pattern to the other two failing tests that
currently repeat `text` (the blocks around the other occurrences noted in the
comment) so each fragment (e.g., RETURNING, LIMIT 1, etc.) is asserted via
toContain on the captured sqlArg.text rather than repeated keys in
expect.objectContaining.
---
Outside diff comments:
In `@__tests__/unit/tcs-config.logic.service.test.ts`:
- Around line 445-475: The test "should add mapping to existing mappings"
currently only calls tcsConfigService.handleAddMapping and doesn't assert
behavior; update the test to assert the returned result equals the
mockUpdatedConfig and verify tcsConfigRepository.findConfigById and
tcsConfigRepository.updateConfig were called with the expected arguments (id,
tenant id and the updated mapping payload where newMapping.source has been
normalized to an array). Do the same for the related "should add function with
default empty arrays" test: assert the returned value, and verify repository
calls include the default-empty-array normalization for function properties so
the tests validate the intended additions rather than merely ensuring no
exception was thrown.
- Around line 271-277: The test calls tcsConfigService.handleUpdateConfig with a
stale 4th argument (timestamp) but the service signature is
handleUpdateConfig(id, tenantId, updates); remove the trailing
'2026-04-07T10:00:00.000Z' from the test invocation so it calls
handleUpdateConfig(1, mockTenantId, { msgFam: 'Updated' }) and adjust any
related expectations/mocks referencing the old 4th param accordingly.
- Around line 600-642: Remove the duplicated test blocks that repeat the same
assertions: delete one of the two identical "should set mapping to empty array
when last mapping is removed" tests that exercise
tcsConfigService.handleRemoveMapping (the duplicated test bodies that mock
tcsConfigRepository.findConfigById and updateConfig and assert updateConfig
called with { mapping: [] }), and likewise delete one of the two identical
"should set functions to empty array when last function is removed" tests that
exercise tcsConfigService.handleRemoveFunction; keep a single instance of each
test case so only one test per behavior remains.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fcf22ce2-3e75-4bef-b381-b98c8742270d
📒 Files selected for processing (8)
__tests__/unit/masking.logic.service.test.ts__tests__/unit/repositories/masking.repository.test.ts__tests__/unit/repositories/network.map.repository.test.ts__tests__/unit/repositories/rule-flow.repository.test.ts__tests__/unit/repositories/simulation-logs.repository.test.ts__tests__/unit/rule.logic.service.test.ts__tests__/unit/tcs-config.logic.service.test.ts__tests__/unit/tcs.config.repository.test.ts
…itory tests Co-authored-by: Copilot <copilot@github.com>
… feat-paysys-test-coverage
SPDX-License-Identifier: Apache-2.0
This pull request significantly expands the test coverage for the masking repository and masking logic service, and introduces new tests for update and review functionality. It also adds tests for date filtering in rule logic and corrects a database query in the network map repository tests. The main improvements focus on ensuring robust handling of create, read, update, and review operations for masking configurations, as well as better validation of query construction and error handling.
Masking Repository and Logic Service Enhancements:
Expanded CRUD Test Coverage:
createMasking,findMaskByIdInDB, andupdateMaskingInDBfunctions, including handling of valid/invalid inputs, error scenarios, and SQL query correctness.Masking Logic Service:
handleUpdateMask, covering successful updates, error handling, and updating with multiple fields.handleGetMaskById, verifying retrieval, not found, and error scenarios.handleReviewMask, including approval, rejection (with/without comments), validation of review status, comment trimming, and error handling.Rule Logic Service Improvements:
startDateandendDateindependently, ensuring correct SQL WHERE clause construction.Network Map Repository:
UPDATEstatement.How was it tested?
Release Notes
Tests
Bug Fixes