chore(e2e): Fix tests after FastEndpoints casing change #1432
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThis pull request introduces modifications to error handling in two test files. In Changes
Possibly related PRs
Suggested reviewers
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
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
tests/k6/tests/serviceowner/dialogCreateInvalidActionCount.js (2)
8-9: Fix typo in error message.There's a typo in the error message: 'reponse' should be 'response'.
-expect(r.json(), 'reponse').to.have.property('errors'); +expect(r.json(), 'response').to.have.property('errors');
Line range hint
14-24: Consider improving code maintainability.The helper function could be improved in the following ways:
- Use a for loop instead of a while loop for better readability
- Consider using an enum or constants for action types
let createDialogWithGuiActions = function(numActions, actionType) { let dialog = dialogToInsert(); dialog.guiActions = []; - while (numActions--) { - let id = `foo${numActions}`; + for (let i = 0; i < numActions; i++) { + let id = `foo${i}`; dialog.guiActions.push( { action: id, title: [{ languageCode: "nb", value: id }], url: `foo:${id}`, priority: actionType } ) } return dialog; };Consider adding action type constants at the top of the file:
const ACTION_TYPES = { PRIMARY: 'primary', SECONDARY: 'secondary', TERTIARY: 'tertiary' };tests/k6/tests/enduser/dialogSearch.js (1)
Line range hint
264-274: Track the disabled test case.The test for org filter functionality is commented out due to incomplete TTD handling. While the comment provides context, it would be beneficial to track this technical debt to ensure it's not forgotten.
Would you like me to help create a GitHub issue to track the re-enabling of this test case once TTD handling is properly implemented?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
tests/k6/tests/enduser/dialogSearch.js(1 hunks)tests/k6/tests/serviceowner/dialogCreateInvalidActionCount.js(1 hunks)
🔇 Additional comments (4)
tests/k6/tests/serviceowner/dialogCreateInvalidActionCount.js (2)
11-11: LGTM: Property casing update aligns with FastEndpoints changes.
The change from GuiActions to guiActions in the error response check correctly aligns with the FastEndpoints casing changes mentioned in the PR title.
Line range hint 31-39: LGTM: Test cases are well-structured and comprehensive.
The test cases effectively cover validation scenarios for different action types and counts, ensuring the API correctly rejects invalid combinations.
tests/k6/tests/enduser/dialogSearch.js (2)
207-207: LGTM: Error property case change aligns with FastEndpoints conventions.
The change from "Process" to "process" in the error property access correctly aligns with the FastEndpoints casing conventions.
207-207: Verify consistent error property casing across test files.
Let's ensure other test files are consistently using the new lowercase casing for error properties.
✅ Verification successful
Property casing is consistent across test files
Based on the comprehensive search results, all error property assertions in the test files are using consistent lowercase casing for error properties. The reviewed line is consistent with the rest of the codebase where:
- Error property checks use lowercase:
.property('errors') - Nested error properties like
processandguiActionsalso use lowercase - No instances of uppercase error property names were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find potential inconsistent error property casing in test files
# Look for error property access patterns that might need updating
# Search for uppercase error property access
rg -g '*.js' '"[A-Z][a-zA-Z]*".*errors'
# Search for specific process error property with potential wrong casing
rg -g '*.js' 'errors.*Process'
Length of output: 74
Script:
#!/bin/bash
# Let's try a more comprehensive search for error property patterns in test files
# Search for any error property access patterns
rg -g '*.js' 'errors.*property|expect.*errors' -B 1 -A 1
# Search for any error-related assertions
rg -g '*.js' 'expect.*json\(\)\.errors' -B 1 -A 1
# Look specifically in the test directory
rg -g '*.js' 'errors' tests/ -B 1 -A 1
Length of output: 10851
oskogstad
changed the title
|
Summary by CodeRabbit