chore(cypess): extend questions workflow with extended coverage of question creation and editing #4418
Conversation
…estion creation and editing
Current Aviator status
This PR was merged manually (without Aviator). Merging manually can negatively impact the performance of the queue. Consider using Aviator next time.
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
📝 WalkthroughWalkthroughThe pull request enhances the Cypress end-to-end test suite for question workflows by introducing a comprehensive set of constants for various question types and their attributes, including titles, content, choices, and editing states. The existing test cases have been refactored to utilize these constants, improving readability and maintainability. Adjustments include increased wait times for actions and the addition of new tests to verify the functionality of creating, editing, and storing questions. Furthermore, the GitHub Actions workflow has been modified to trigger tests when changes occur in the Changes
Possibly related PRs
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 (
|
![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
🧹 Nitpick comments (9)
cypress/cypress/e2e/D-questions-workflow.cy.ts (9)
4-7: Group constants in a single structure for scalability
These constants for the content element look fine. For future expansion, consider grouping them inside a descriptive container object to keep related constants together and reduce repetition.
Line range hint
67-99: Use Cypress commands instead of fixed waits
The test accurately creates a content element but relies oncy.wait(1000)at line 91. Consider using Cypress built-in.should('be.visible'),.should('not.be.disabled'), or other event-driven checks to avoid flakiness and reduce overall test time.
113-134: Solid edit workflow for content element
The test ensures that new title, text, and status changes persist. Adding a negative test (e.g., clearing required fields) could strengthen coverage.
Line range hint
151-180: Flashcard creation with forced waits
The test coverage is thorough for creating flashcard elements, but keep in mind thatcy.wait(1000)at line 173 could be replaced by more deterministic approaches (e.g.,.should('be.visible')).
243-284: Single choice question creation flow
The logic preventing saving until a proper choice is entered is a strong approach. Consider removing manual waits (likecy.wait(500)) in favor of event-based checks to reduce test runtime.
Line range hint
370-430: Multiple choice setup
Again consider replacingcy.wait(500)with.should(...)or other cypress wait strategies. This will stabilize tests and reduce reliance on arbitrary intervals.
Line range hint
549-632: KPRIM question creation
The complex rearranging of answer fields is a good stress test of UI reordering. Again, consider awaiting element states instead of fixedcy.wait(500).
Line range hint
734-776: Creating a numerical question
Relies on a mandatory field approach before enabling save. A more event-driven wait rather thancy.wait(1000)at line 761 is recommended.
Line range hint
891-922: Creating a free text question
The approach is consistent with other types. Replacingcy.wait(500)with.should(...)checks can help reduce flakiness.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
cypress/cypress/e2e/D-questions-workflow.cy.ts(8 hunks)
🔇 Additional comments (25)
cypress/cypress/e2e/D-questions-workflow.cy.ts (25)
9-14: Flashcard constants look good
The naming and consistency align well with the content element constants. No issues found.
16-22: Single choice question constants
Neat approach to define initial and edited titles, content, and choices. This helps ensure clarity and maintainability of the test code.
23-29: Multiple choice question constants
Consistent array usage for choices. Nicely parallels the single choice setup.
30-36: KPRIM question constants
Straightforward naming convention. Keeps the code readable and easy to maintain.
37-53: Numerical range constants
Defining range boundaries, accuracy, and unit in separate constants is a clear approach. This will simplify updates and expansions.
55-65: Free text question constants
Clear naming and inclusion of sample solutions improves test reliability by verifying user input across multiple solution strings.
100-111: Good verification of content element persistence
This block confirms that values are properly stored and reloaded. You could expand coverage by testing edge cases such as empty or invalid content.
136-149: Verifying edited content element
These checks confirm that the updated title and text are displayed. Straightforward and effective.
182-196: Flashcard persistence checks
Ensuring the flashcard retains its title, status, and explanation fosters high confidence in data integrity. This is solid.
198-223: Editing flashcard with status change
Comprehensive coverage of changing and verifying text, explanation, and status. Good job.
225-241: Verifying edited flashcard
The checks confirm the new values and status. This closes the feature completeness loop for flashcards.
286-304: Single choice question storage validation
All essential fields are confirmed—title, status, and each registered choice. The test has a clear flow.
305-368: Editing single choice with sample solution
Thoroughly tests toggling correct answers and removing/adding answer options. This helps catch corner cases.
431-451: Multiple choice question validation
Reads back the question's title, status, and choices. Maintains consistent patterns with the single choice tests.
453-547: Extensive editing for multiple choice
Adding and deleting answers, setting correctness states, and verifying the final state covers key scenarios comprehensively.
636-661: KPRIM question stored values
Checks exist for the correct question type label, title, status, and rearranged answers. Nicely done.
663-732: Editing KPRIM question
Removing answers, adding new ones, and toggling correctness is tested thoroughly. The “no correct solution required” logic is well handled.
777-798: Confirming numerical question data
Verifies each numerical field is displayed correctly, including unit and accuracy. Straightforward and effective.
800-848: Editing and adding solution ranges
Excellent coverage adding multiple solution ranges. Ensuring at least one valid range is mandatory is tested well.
850-889: Verifying edited numerical question
Checks that revised min, max, and solution ranges persist and are displayed. This ensures data integrity.
923-932: Confirm free text question
Validates title, status, and text presence. Straightforward coverage.
934-962: Editing free text question with sample solutions
Ensures mandatory sample solutions are added before saving. This test comprehensively checks the entire editing flow.
963-980: Verifying edited free text question
Checks new title, content, length, and sample solutions. The coverage is robust.
Line range hint 981-1024: Duplicate and delete question flow
Ensures that duplication works correctly and deletion of the duplicate is successful. Great feature coverage.
1026-1054: Cleanup routine
Systematically deleting all created questions helps avoid test pollution in subsequent runs. Good closure step.
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/cypress-testing.yml (2)
Line range hint
1-150: Consider workflow optimizations for faster CI runs.While the current workflow is well-structured, here are some potential optimizations to consider:
- Uncomment and enable parallel test execution using the matrix strategy
- Consider using dependency caching more aggressively
- Enable test splitting and parallelization with Cypress
Apply these changes to optimize the workflow:
strategy: - # fail-fast: false # https://github.com/cypress-io/github-action/issues/48 - # matrix: - # containers: [1, 2] # Run parallel instances + fail-fast: false + matrix: + containers: [1, 2] # In the Cypress step - name: Cypress run uses: cypress-io/github-action@v6 timeout-minutes: 60 with: install: false wait-on: 'http://127.0.0.1:3000/healthz, http://127.0.0.1:3001, http://127.0.0.1:3002, http://127.0.0.1:3003, http://127.0.0.1:3010' wait-on-timeout: 300 record: true browser: electron working-directory: cypress - # parallel: true + parallel: true
Line range hint
118-150: Consider enabling code coverage reporting.The commented-out code coverage configuration could be valuable for tracking test coverage metrics. Consider enabling it to ensure the extended question workflow tests maintain good coverage.
Uncomment and update the coverage configuration:
- # - name: Archive code coverage results - # uses: actions/upload-artifact@v3 - # with: - # name: code-coverage - # path: cypress/coverage - - # - name: Coveralls - # uses: coverallsapp/github-action@v2 + - name: Archive code coverage results + uses: actions/upload-artifact@v3 + with: + name: code-coverage + path: cypress/coverage + retention-days: 14 + + - name: Upload coverage to Coveralls + uses: coverallsapp/github-action@v2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/cypress-testing.yml(1 hunks)
🔇 Additional comments (1)
.github/workflows/cypress-testing.yml (1)
14-14: LGTM! Path filter addition aligns with PR objectives.
The addition of the cypress/** path filter ensures that the Cypress tests will run when test files are modified, which is essential for the extended question workflow coverage being added in this PR.
klicker-uzh
|
||||||||||||||||||||||||||||
| Project |
klicker-uzh
|
| Branch Review |
element-test-suite-extension
|
| Run status |
|
| Run duration | 13m 29s |
| Commit |
|
| Committer | Julius Schlapbach |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
172
|
| View all changes introduced in this branch ↗︎ | |
klicker-uzh
|
||||||||||||||||||||||||||||
| Project |
klicker-uzh
|
| Branch Review |
v3-new-elements
|
| Run status |
|
| Run duration | 13m 25s |
| Commit |
|
| Committer | Julius Schlapbach |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
|
Failures
|
0
|
|
Flaky
|
0
|
|
Pending
|
0
|
|
Skipped
|
0
|
|
Passing
|
172
|
| View all changes introduced in this branch ↗︎ | |
Summary by CodeRabbit
cypress/**directory.