fix(debug): hide dummypay from configs response when not in debug mode #316
Conversation
WalkthroughThe pull request updates numerous service initialization functions across the codebase to include an additional boolean parameter, commonly representing a debug flag. This flag is now passed to various service constructors and test cases, altering the configuration behavior. Additionally, the changes standardize the dummy PSP name by introducing a constant and modifying the configuration retrieval functions to conditionally hide dummy PSP settings when debug mode is off. A new debug option is also added in the test server configuration. Changes
Sequence Diagram(s)sequenceDiagram
participant C as Caller/Test
participant S as Service
participant R as Registry
C->>S: New(store, eng, debug)
Note right of S: Service initialized with debug flag
S->>R: ConnectorsConfigs() calls GetConfigs(debug)
R-->>S: Return Configs (dummy PSP hidden if debug is false)
S-->>C: Return Configs
Assessment against linked issues
Poem
Tip 🌐 Web search-backed reviews and chat
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #316 +/- ##
==========================================
+ Coverage 72.89% 72.91% +0.01%
==========================================
Files 541 541
Lines 27335 27338 +3
==========================================
+ Hits 19927 19934 +7
+ Misses 6335 6333 -2
+ Partials 1073 1071 -2 ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (8)
internal/api/services/connector_configs_test.go (1)
20-20: Add test case for debug mode.While the current test verifies basic functionality, consider adding a test case with
debug=trueto ensure the debug flag correctly affects the configs response.func TestConnectorConfigs(t *testing.T) { t.Parallel() + testCases := []struct { + name string + debug bool + validate func(*testing.T, registry.Configs) + }{ + { + name: "debug mode off", + debug: false, + validate: func(t *testing.T, configs registry.Configs) { + require.NotNil(t, configs) + // Add assertions to verify dummypay is not present + }, + }, + { + name: "debug mode on", + debug: true, + validate: func(t *testing.T, configs registry.Configs) { + require.NotNil(t, configs) + // Add assertions to verify dummypay is present + }, + }, + } + + for _, tc := range testCases { + tc := tc + t.Run(tc.name, func(t *testing.T) { + t.Parallel() + ctrl := gomock.NewController(t) + defer ctrl.Finish() + store := storage.NewMockStorage(ctrl) + eng := engine.NewMockEngine(ctrl) + + s := New(store, eng, tc.debug) + tc.validate(t, s.ConnectorsConfigs()) + }) + } }internal/api/services/payments_get_test.go (2)
23-23: Consider creating a test helper for service initialization.Given the consistent pattern of service initialization across test files, consider creating a test helper function that encapsulates the service creation logic with debug mode parameter. This would make it easier to maintain and modify the initialization behavior across all test files.
+func newTestService(t *testing.T, debugMode bool) *Service { + ctrl := gomock.NewController(t) + t.Cleanup(func() { ctrl.Finish() }) + store := storage.NewMockStorage(ctrl) + eng := engine.NewMockEngine(ctrl) + return New(store, eng, debugMode) +} func TestPaymentGet(t *testing.T) { t.Parallel() - - ctrl := gomock.NewController(t) - defer ctrl.Finish() - store := storage.NewMockStorage(ctrl) - eng := engine.NewMockEngine(ctrl) - - s := New(store, eng, false) + s := newTestService(t, false)
23-23: Consider table-driven tests for debug mode configurations.The changes consistently add a debug flag parameter across all test files, but there's an opportunity to improve the test architecture:
- Create a shared test helper for service initialization
- Add table-driven tests to verify behavior in both debug and non-debug modes
- Consider creating a shared test suite for debug-mode-specific behaviors that can be reused across test files
This would improve maintainability and ensure consistent coverage of debug mode behavior across all service tests.
internal/api/services/accounts_get_test.go (1)
24-24: Add test cases for debug mode.While setting
debug=falsealigns with production behavior, consider adding test cases withdebug=trueto ensure both modes work as expected.Example test table modification:
tests := []struct { name string accountID models.AccountID err error expectedError error + debug bool }{ { name: "success without debug", accountID: id, err: nil, expectedError: nil, + debug: false, }, + { + name: "success with debug", + accountID: id, + err: nil, + expectedError: nil, + debug: true, + },internal/api/services/bank_accounts_forward_to_connector_test.go (1)
64-65: Document the debug parameter's purpose.The
debugparameter is being passed through multiple layers. Consider adding a comment explaining its purpose and impact on theForwardBankAccountoperation.+// debug flag controls whether dummy/test configurations are included in responses eng.EXPECT().ForwardBankAccount(gomock.Any(), test.bankAccountID, connectorID, false).Return(models.Task{}, test.err)internal/api/services/connectors_uninstall_test.go (1)
23-23: Consider parameterizing the debug flag in tests.The debug flag is hardcoded to
false. Consider parameterizing it through test cases to verify behavior in both modes.tests := []struct { name string engineErr error storageErr error expectedError error typedError bool + debug bool }{ { name: "success", engineErr: nil, storageErr: nil, expectedError: nil, + debug: false, }, + { + name: "success with debug mode", + engineErr: nil, + storageErr: nil, + expectedError: nil, + debug: true, + },internal/api/services/payment_initiation_adjustments_get_last_test.go (1)
25-25: Add test coverage for debug mode configuration.The service is initialized with
debug=false, but there's no test coverage for debug mode behavior. Consider adding test cases to verify both configurations.Example test setup:
s := New(store, eng, false) +s_debug := New(store, eng, true) tests := []struct { name string storageResponse []models.PaymentInitiationAdjustment err error expectedError error + useDebugService bool }{ { name: "success", err: nil, storageResponse: []models.PaymentInitiationAdjustment{{}}, expectedError: nil, + useDebugService: false, }, + { + name: "success with debug mode", + err: nil, + storageResponse: []models.PaymentInitiationAdjustment{{}}, + expectedError: nil, + useDebugService: true, + },internal/connectors/plugins/registry/plugins.go (1)
127-137: LGTM with a documentation suggestion.The implementation correctly controls the visibility of the dummy PSP based on the debug mode. Consider adding a comment explaining why the dummy PSP should be hidden in non-debug mode for better maintainability.
func GetConfigs(debug bool) Configs { confs := make(Configs) for key, info := range pluginsRegistry { - // hide dummy PSP outside of debug mode + // Hide dummy PSP outside of debug mode to prevent its usage in production + // as it's intended only for testing and development purposes if !debug && key == DummyPSPName { continue } confs[key] = info.config } return confs }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (49)
internal/api/module.go(1 hunks)internal/api/services/accounts_create_test.go(1 hunks)internal/api/services/accounts_get_test.go(1 hunks)internal/api/services/accounts_list_test.go(1 hunks)internal/api/services/balances_list_test.go(1 hunks)internal/api/services/bank_accounts_create_test.go(1 hunks)internal/api/services/bank_accounts_forward_to_connector_test.go(1 hunks)internal/api/services/bank_accounts_get_test.go(1 hunks)internal/api/services/bank_accounts_list_test.go(1 hunks)internal/api/services/bank_accounts_update_metadata_test.go(1 hunks)internal/api/services/connector_configs.go(1 hunks)internal/api/services/connector_configs_test.go(1 hunks)internal/api/services/connectors_config_update_test.go(1 hunks)internal/api/services/connectors_handle_webhooks_test.go(1 hunks)internal/api/services/connectors_install_test.go(1 hunks)internal/api/services/connectors_list_test.go(1 hunks)internal/api/services/connectors_reset_test.go(1 hunks)internal/api/services/connectors_uninstall_test.go(1 hunks)internal/api/services/payment_initiation_adjustments_get_last_test.go(1 hunks)internal/api/services/payment_initiation_adjustments_list_test.go(2 hunks)internal/api/services/payment_initiation_related_payments_list_test.go(2 hunks)internal/api/services/payment_initiations_approve_test.go(1 hunks)internal/api/services/payment_initiations_create_test.go(1 hunks)internal/api/services/payment_initiations_delete_test.go(1 hunks)internal/api/services/payment_initiations_get_test.go(1 hunks)internal/api/services/payment_initiations_list_test.go(1 hunks)internal/api/services/payment_initiations_reject_test.go(1 hunks)internal/api/services/payment_initiations_retry_test.go(1 hunks)internal/api/services/payment_initiations_reversal_create_test.go(1 hunks)internal/api/services/payments_create_test.go(1 hunks)internal/api/services/payments_get_test.go(1 hunks)internal/api/services/payments_list_test.go(1 hunks)internal/api/services/payments_update_metadata_test.go(1 hunks)internal/api/services/pools_add_account_test.go(1 hunks)internal/api/services/pools_balances_at_test.go(1 hunks)internal/api/services/pools_create_test.go(1 hunks)internal/api/services/pools_delete_test.go(1 hunks)internal/api/services/pools_get_test.go(1 hunks)internal/api/services/pools_list_test.go(1 hunks)internal/api/services/pools_remove_account_test.go(1 hunks)internal/api/services/schedules_get_test.go(1 hunks)internal/api/services/schedules_list_test.go(1 hunks)internal/api/services/services.go(1 hunks)internal/api/services/tasks_get_test.go(1 hunks)internal/api/services/workflows_instances_list_test.go(1 hunks)internal/connectors/plugins/public/dummypay/plugin.go(1 hunks)internal/connectors/plugins/registry/plugins.go(2 hunks)internal/connectors/plugins/registry/plugins_test.go(7 hunks)test/e2e/api_connectors_test.go(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- internal/connectors/plugins/public/dummypay/plugin.go
🔇 Additional comments (44)
internal/api/services/services.go (1)
11-11: LGTM! Clean addition of debug flag.The addition of the debug field and its constructor initialization is well-structured and follows Go conventions.
Also applies to: 14-19
internal/api/services/connector_configs.go (1)
11-13: LGTM! Clean implementation of debug-controlled config visibility.The modification correctly passes the debug flag to control config visibility, implementing the PR objective.
internal/api/module.go (1)
35-35: LGTM! Proper propagation of debug flag.The change correctly propagates the debug flag from module initialization to service creation.
internal/api/services/payments_list_test.go (1)
22-22: Add test coverage for debug mode.Given that this PR modifies dummy payment provider behavior based on debug mode, consider adding test cases with
debug=trueto verify the service behaves correctly in both modes.internal/api/services/balances_list_test.go (1)
22-22: Add test coverage for debug mode.Since balances may be associated with dummy payment providers, consider adding test cases with
debug=trueto ensure the service behaves correctly in both modes.internal/api/services/schedules_list_test.go (1)
22-22: LGTM! Consider adding debug mode test cases.The addition of the debug flag parameter is consistent with the PR objective. Since this change introduces a new configuration option, consider adding test cases that verify the behavior in debug mode.
internal/api/services/connectors_list_test.go (1)
22-22: Add test coverage for connector config visibility.Since this PR deals with hiding "dummypay" from configs response, and this test file handles connector listing, consider adding test cases that verify:
- Connector configs are properly filtered in non-debug mode
- All configs (including dummypay) are visible in debug mode
internal/api/services/workflows_instances_list_test.go (1)
22-22: LGTM!The addition of the debug flag parameter is consistent with the codebase changes.
internal/api/services/bank_accounts_list_test.go (2)
22-22: LGTM!The addition of the debug flag parameter is consistent with the codebase changes.
22-22: Verify consistent debug flag usage across test files.Let's verify that all test files consistently handle the debug flag parameter.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Check for consistent debug flag usage in test files # Find all test files in the services package and check New function calls echo "Checking debug flag usage in test files..." rg -U "s := New\([^)]+\)" "internal/api/services/*_test.go" # Find any test files that might be testing debug-specific behavior echo -e "\nChecking for debug-specific test cases..." rg -i "debug.*mode|mode.*debug" "internal/api/services/*_test.go"Length of output: 467
🏁 Script executed:
#!/bin/bash set -e echo "Listing all Go test files in the repository..." fd -e go '_test\.go$' echo -e "\nSearching for 'New(' calls in test files with assignment to variable 's'..." fd -e go '_test\.go$' -x rg -U "s := New\([^)]*\)" echo -e "\nSearching for any 'New(' calls in test files that pass debug flag as true..." fd -e go '_test\.go$' -x rg -U "New\([^,]+,\s*[^,]+,\s*true\)"Length of output: 16651
Consistent Debug Flag Usage Confirmed
All test files invoking the New() function are consistently passing the debug flag as false, including the instance in internal/api/services/bank_accounts_list_test.go. There were no occurrences of the debug flag being set to true.
internal/api/services/tasks_get_test.go (1)
23-23: Consider adding test cases for debug mode behavior.While the addition of the debug flag parameter is consistent, consider adding test cases that verify the service behavior in both debug and non-debug modes to ensure complete test coverage.
func TestTasksGet(t *testing.T) { t.Parallel() ctrl := gomock.NewController(t) defer ctrl.Finish() store := storage.NewMockStorage(ctrl) eng := engine.NewMockEngine(ctrl) - s := New(store, eng, false) + tests := []struct { + name string + debugMode bool + }{ + { + name: "with debug mode off", + debugMode: false, + }, + { + name: "with debug mode on", + debugMode: true, + }, + } - tests := []struct { + for _, mode := range tests { + s := New(store, eng, mode.debugMode)internal/api/services/payment_initiations_list_test.go (1)
22-22: Similar feedback applies to debug mode test coverage.internal/api/services/bank_accounts_create_test.go (1)
23-23: Similar feedback applies to debug mode test coverage.internal/api/services/pools_get_test.go (1)
24-24: LGTM! Verify debug mode behavior.The addition of the debug flag parameter aligns with the PR objectives. Since this test covers non-debug mode scenarios, consider adding test cases for debug mode to ensure complete coverage.
internal/api/services/bank_accounts_update_metadata_test.go (1)
23-23: LGTM!The addition of the debug flag parameter is consistent with other test files and maintains existing test coverage.
internal/api/services/connectors_config_update_test.go (1)
25-25: Add test coverage for debug mode configuration.While the change aligns with PR objectives, consider adding test cases to verify that:
- Dummypay config is hidden when debug is false
- Dummypay config is visible when debug is true
This ensures the core functionality of hiding dummypay in non-debug mode is properly tested.
internal/api/services/payments_update_metadata_test.go (1)
23-23: LGTM!The addition of the debug flag parameter is consistent with other test files and maintains existing test coverage.
internal/api/services/schedules_get_test.go (1)
23-23: Consider adding test cases for debug mode behavior.While the addition of the debug parameter is consistent, consider adding test cases that verify how the debug flag affects the service behavior, if applicable to schedule operations.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Check if debug flag affects schedule-related operations ast-grep --pattern 'func (s *Service) SchedulesGet($$$) { $$$ if s.debug { $$$ } $$$ }'Length of output: 101
Debug Mode Behavior for SchedulesGet Is Not Currently Exercised
Our investigation confirms that the
SchedulesGetfunctionality does not conditionally branch on the debug flag—even though theNewmethod now accepts a debug parameter, there isn’t any logic withinSchedulesGet(or its related flows) that leverages the value ofs.debug. As such, adding tests specifically for debug-mode behavior isn’t necessary at this moment. If future changes introduce debug-specific handling in schedule operations, then test coverage should be revisited.internal/api/services/bank_accounts_get_test.go (1)
24-24: LGTM! Consider adding debug mode test cases.The change is consistent with the service constructor update. If bank account operations are affected by debug mode, consider adding test cases to verify the behavior in both debug and non-debug modes.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Check if debug flag affects bank account operations ast-grep --pattern 'func (s *Service) BankAccountsGet($$$) { $$$ if s.debug { $$$ } $$$ }'Length of output: 104
Attention: No Debug Mode Handling Found
Our verification indicates that the
BankAccountsGetimplementation does not conditionally check or modify its behavior based on the service’sdebugflag. The updated test case correctly reflects the updated constructor signature. If future changes introduce debug-dependent behavior for bank account operations, then adding debug mode test cases would be beneficial.internal/api/services/payment_initiations_get_test.go (1)
23-23: LGTM! Consider adding debug mode test cases.The change is consistent with the service constructor update. If payment initiation operations are affected by debug mode, consider adding test cases to verify the behavior in both debug and non-debug modes.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Check if debug flag affects payment initiation operations ast-grep --pattern 'func (s *Service) PaymentInitiationsGet($$$) { $$$ if s.debug { $$$ } $$$ }'Length of output: 110
I'll generate an additional shell script to search for the
PaymentInitiationsGetfunction definition and check for any usage of thes.debugflag within that function's file. This will help us verify whether the debug mode affects the payment initiation operations.
🏁 Script executed:
#!/bin/bash # Find the file(s) that define the PaymentInitiationsGet function in the services package. FILE=$(rg -l "func (s\\*Service) PaymentInitiationsGet" internal/api/services/) echo "File(s) with PaymentInitiationsGet function:" echo "$FILE" # If a file is found, search within it for any usage of the debug flag. if [ -n "$FILE" ]; then echo -e "\nSearching for debug flag usage in the PaymentInitiationsGet function file(s):" rg -n "s\.debug" $FILE else echo "PaymentInitiationsGet function file not found." fiLength of output: 310
I'll run an additional script to search for any reference to
PaymentInitiationsGetin the repository to better understand its presence and whether it inspects the debug flag.
🏁 Script executed:
#!/bin/bash # Search for any occurrence of 'PaymentInitiationsGet' in the repository. rg -n "PaymentInitiationsGet" .Length of output: 20016
Payment Initiations Get Operation Unaffected by Debug Mode
Our investigation shows that the
PaymentInitiationsGetfunction ininternal/api/services/payment_initiations_get.godoes not utilize thedebugflag (i.e., there’s no branch condition or behavior change based ons.debug). This confirms that while the constructor update to include thefalseparameter is consistent, there isn’t any debug-specific behavior to test for in this function at present.
- The code in
internal/api/services/payment_initiations_get.gosimply callss.storage.PaymentInitiationsGetwithout checking the debug flag.- No alternative paths or conditional logic based on debug mode is detected.
The current tests are comprehensive for the error scenarios, and additional debug mode test cases aren’t necessary unless future changes introduce debug-sensitive behavior.
internal/api/services/pools_delete_test.go (2)
23-24: Verify the broader impact of debug mode.While the changes consistently add the debug parameter across all service tests, it would be beneficial to verify how this flag affects the overall system behavior, particularly around dummy PSP visibility as mentioned in the PR objectives.
23-23: LGTM! Consider adding debug mode test cases.The change is consistent with the service constructor update. If pool operations are affected by debug mode, consider adding test cases to verify the behavior in both debug and non-debug modes.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Check if debug flag affects pool operations ast-grep --pattern 'func (s *Service) PoolsDelete($$$) { $$$ if s.debug { $$$ } $$$ }'Length of output: 100
Code Consistency Verified – Debug Mode Not Currently Impacting Pool Deletion
After verifying the code and checking for any conditional behavior involving the debug flag in the pool deletion logic, no branches (e.g., “if s.debug …”) were found in the
PoolsDeleteimplementation. This confirms that the updated constructor parameter (falsein this test) does not affect pool deletion behavior.The current tests correctly cover error cases without needing to exercise separate debug mode behavior. If, in the future, pool operations are meant to behave differently when debug mode is enabled, then adding corresponding test cases would be advisable.
internal/api/services/pools_create_test.go (1)
23-23: Consider adding test cases for debug mode behavior.While the debug flag is added, consider adding test cases that validate the service behavior in both debug and non-debug modes to ensure complete test coverage.
internal/api/services/accounts_create_test.go (1)
23-23: Same debug mode test coverage concern as in pools_create_test.go.internal/api/services/payments_create_test.go (1)
23-23: Same debug mode test coverage concern as in pools_create_test.go.internal/api/services/connectors_reset_test.go (1)
23-23: 🛠️ Refactor suggestionAdd connector-specific debug mode test cases.
Since this PR aims to hide "dummypay" from configs in non-debug mode, consider adding specific test cases to validate:
- Connector reset behavior in debug mode
- Connector reset behavior in non-debug mode, especially regarding dummypay visibility
Add test cases by extending the test struct:
tests := []struct { name string + debug bool err error expectedError error typedError bool }{ { name: "success", + debug: false, err: nil, expectedError: nil, }, + { + name: "success with debug mode", + debug: true, + err: nil, + expectedError: nil, + }, // ... other test cases }Then update the test execution:
for _, test := range tests { t.Run(test.name, func(t *testing.T) { + s := New(store, eng, test.debug) eng.EXPECT().ResetConnector(gomock.Any(), models.ConnectorID{}).Return(models.Task{}, test.err)internal/api/services/connectors_handle_webhooks_test.go (1)
23-23: Add test coverage for debug mode.The test only covers non-debug mode (
false). Consider adding test cases with debug mode enabled (true) to ensure the service behaves correctly in both modes.internal/api/services/connectors_install_test.go (1)
23-23: Add test coverage for debug mode.The test only covers non-debug mode (
false). Consider adding test cases with debug mode enabled (true) to ensure the service behaves correctly in both modes.internal/api/services/pools_add_account_test.go (1)
24-24: Add test coverage for debug mode.The test only covers non-debug mode (
false). Consider adding test cases with debug mode enabled (true) to ensure the service behaves correctly in both modes.internal/api/services/pools_remove_account_test.go (1)
24-24: Add test coverage for debug mode.The test only covers non-debug mode (
false). Consider adding test cases with debug mode enabled (true) to ensure the service behaves correctly in both modes.internal/api/services/pools_balances_at_test.go (1)
26-26: LGTM!The addition of the debug flag parameter is consistent with the PR objectives to control the visibility of dummy PSP configurations.
internal/api/services/payment_initiation_adjustments_list_test.go (1)
24-24: LGTM!The addition of the debug flag parameter in both test functions is consistent with the PR objectives to control the visibility of dummy PSP configurations.
Also applies to: 72-72
internal/api/services/payment_initiation_related_payments_list_test.go (1)
24-24: LGTM!The addition of the debug flag parameter in both test functions is consistent with the PR objectives to control the visibility of dummy PSP configurations.
Also applies to: 72-72
internal/connectors/plugins/registry/plugins.go (1)
16-16: LGTM!The constant definition follows Go naming conventions and improves code maintainability.
internal/api/services/payment_initiations_create_test.go (1)
24-24: LGTM!The service constructor is correctly updated to include the debug flag parameter set to false, which aligns with the PR objective.
internal/api/services/payment_initiations_delete_test.go (1)
25-25: LGTM!The service constructor is correctly updated to include the debug flag parameter set to false, which aligns with the PR objective.
internal/api/services/payment_initiations_reject_test.go (1)
25-25: LGTM!The service constructor is correctly updated to include the debug flag parameter set to false, which aligns with the PR objective.
internal/connectors/plugins/registry/plugins_test.go (3)
51-51: LGTM!The DummyPSPName plugin is correctly registered with the same capabilities and configuration as other plugins.
53-113: LGTM!All existing test cases are correctly updated to explicitly pass debug=false, maintaining existing behavior while supporting the new debug flag functionality.
122-132: LGTM!The new test cases effectively verify the dummypay visibility behavior:
- Hidden when debug mode is off
- Visible when debug mode is on
internal/api/services/payment_initiations_reversal_create_test.go (1)
23-23: LGTM!The addition of the debug flag parameter (set to false) aligns with the PR objective of controlling dummypay visibility.
internal/api/services/payment_initiations_retry_test.go (1)
26-26: LGTM!The addition of the debug flag parameter (set to false) is consistent with other test files and supports the PR objective.
internal/api/services/payment_initiations_approve_test.go (1)
26-26: LGTM!The addition of the debug flag parameter (set to false) maintains consistency with other test files and supports the PR objective.
test/e2e/api_connectors_test.go (1)
39-39: LGTM! Verify test coverage for debug mode behavior.The addition of
Debug: truein the test server configuration is appropriate as these e2e tests need access to dummypay connector functionality.Consider adding test cases to verify that:
- Dummypay is visible in the configs response when debug mode is true
- Dummypay is hidden in the configs response when debug mode is false
This can be achieved by adding a new test case in the "fetching connector configurations" section with debug mode set to false.
Fixes: ENG-1587