🚀 Feature: Added end-to-end test cases using testRigor through CI/CD #8102
Conversation
Tweaks to test cases
WalkthroughThis pull request introduces a comprehensive end-to-end testing infrastructure using testRigor. It adds a GitHub Actions workflow for automated E2E test execution, documentation for the testing framework, reusable test rules for common UI interactions, and ten test case scenarios covering key features like user management, work items, cycles, views, and pages. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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 |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This PR is being reviewed by Cursor Bugbot
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| - uses: 'actions/checkout@v4' | ||
| name: 'Checkout' | ||
| with: | ||
| ref: ${{ inputs.refName != '' && inputs.refName || '' }} |
There was a problem hiding this comment.
Bug: Workflow Checks Out Wrong Branch
The workflow references inputs.refName without defining it in the workflow_dispatch section. This will cause the checkout step to receive an empty string for the ref parameter, potentially checking out the wrong branch when manually triggered.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🧹 Nitpick comments (6)
e2etests/rules/quick add work item "workItem" with status "status".txt (1)
1-5: Consider adding verification step.The rule lacks a confirmation check that the work item was successfully created or state changed. Adding
check that page contains stored value "workItem"at the end would improve reliability and catch UI failures earlier.e2etests/rules/create page "pageName" on project "projectName".txt (1)
1-5: Consider adding verification step.The rule could be more robust by verifying the page was created, similar to the work item creation rule. Adding
check that page contains stored value "pageName"before returning to project would catch creation failures.e2etests/testcases/Create a page, validate that other users can modify it.txt (1)
1-20: Consider strengthening the real-time collaboration assertion.The current test validates persistence via reload, which is good. However, to fully validate real-time collaboration, consider adding a step where the admin observes the edit before reload to confirm live updates. This would test WebSocket/real-time sync. That said, the current design with reload is a reasonable baseline and may already be covered by separate real-time tests mentioned in the PR objectives.
e2etests/README.md (2)
11-15: Clarify workflow trigger conditions.The documentation mentions the GitHub Actions workflow triggers but doesn't explicitly list all conditions. While line 32-35 covers CI/CD testing, consider adding a brief note in the "How it Works" section (around line 11) that the workflow runs automatically on
pushto specific branches (tr-e2e-tests,preview) and on pull requests topreview.This would help developers understand when tests execute without needing to review the workflow file directly.
21-27: Add prerequisite installation step to manual testing section.The manual testing code block on line 24-26 shows how to run tests, but the Requirements section above it assumes testRigor CLI is already installed. Consider adding a brief note about installation (e.g.,
npm install -g testrigor-clior equivalent).This improves the documentation's completeness for developers new to testRigor.
e2etests/testcases/Add team member to project,assign a work item to them then validate they see the work item.txt (1)
18-21: Add assertions or error handling to cleanup section.The cleanup section assumes the work item and invited user still exist, but if the test fails partway through (e.g., on line 8 during assignment), the cleanup operations (lines 20-21) might fail without clear error reporting.
Consider adding validation steps before cleanup:
//cleanup + Log stored value "adminUser" to website + check that page contains saved value "workItem" // verify work item still exists before deletion delete work item stored value "workItem" from project stored value "projectName" + check that page does not contain saved value "workItem" // verify deletion succeeded remove user stored value "invitedUser" from project stored value "projectName"This makes test failures easier to diagnose and ensures cleanup actually succeeds.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
.github/workflows/tR-ci.yml(1 hunks)e2etests/README.md(1 hunks)e2etests/rules/Log "user" to website.txt(1 hunks)e2etests/rules/add a cycle "cycleName" to project "projectName".txt(1 hunks)e2etests/rules/add user "userName" to project "projectName".txt(1 hunks)e2etests/rules/add view "viewName" to project "projectName".txt(1 hunks)e2etests/rules/create page "pageName" on project "projectName".txt(1 hunks)e2etests/rules/create user "user" then join workplace.txt(1 hunks)e2etests/rules/create work item "workItem" on project "projectName".txt(1 hunks)e2etests/rules/delete page "pageName" from "projectName".txt(1 hunks)e2etests/rules/delete view "viewName" from project "projectName".txt(1 hunks)e2etests/rules/delete work item "workItem" from project "projectName".txt(1 hunks)e2etests/rules/invite user "userName".txt(1 hunks)e2etests/rules/log out.txt(1 hunks)e2etests/rules/quick add work item "workItem" with status "status".txt(1 hunks)e2etests/rules/remove cycle "cycleName" from project "projectName".txt(1 hunks)e2etests/rules/remove user "userName" from project "projectName".txt(1 hunks)e2etests/testcases/Add team member to project,assign a work item to them then validate they see the work item.txt(1 hunks)e2etests/testcases/Change Project ID, verify that work items get updated accordingly.txt(1 hunks)e2etests/testcases/Change view to board, verify that dragging items to other columns updates their status.txt(1 hunks)e2etests/testcases/Comment on a work item, validate that other users receive notifications on their inbox.txt(1 hunks)e2etests/testcases/Create a page, validate that other users can modify it.txt(1 hunks)e2etests/testcases/Create a view, add work items then drag them.txt(1 hunks)e2etests/testcases/Create a work cycle, add work items, validate that progress is being tracked after work items are tagged as completed.txt(1 hunks)e2etests/testcases/Create an active cycle, check that you cant have more than one active cycle.txt(1 hunks)e2etests/testcases/Validate that quicklinks redirect to the specified page.txt(1 hunks)e2etests/testcases/Validate that search work items by labels is filtering correctly.txt(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-17T10:46:13.825Z
Learnt from: NarayanBavisetti
Repo: makeplane/plane PR: 7969
File: apps/api/plane/api/views/cycle.py:1218-1228
Timestamp: 2025-10-17T10:46:13.825Z
Learning: In the cycle transfer functionality in apps/api/plane/api/views/cycle.py, transfers should only be allowed from completed cycles (end_date < timezone.now()), not from active or draft cycles. The guard should block when end_date is None or end_date >= timezone.now().
Applied to files:
e2etests/testcases/Create an active cycle, check that you cant have more than one active cycle.txt
🪛 actionlint (1.7.8)
.github/workflows/tR-ci.yml
33-33: property "refname" is not defined in object type {}
(expression)
33-33: property "refname" is not defined in object type {}
(expression)
🪛 LanguageTool
e2etests/README.md
[uncategorized] ~11-~11: The official name of this software platform is spelled with a capital “H”.
Context: ...GitHub Actions**: Automated workflow in .github/workflows/tR-ci.yml that: - Sets up...
(GITHUB)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (26)
e2etests/rules/log out.txt (1)
1-2: LGTM!Clean and straightforward logout rule suitable for reuse across test cases.
e2etests/rules/add a cycle "cycleName" to project "projectName".txt (1)
1-9: Verify stored value initialization upstream.The rule depends on
todayDayOfMonthstored value being set. Ensure this is initialized in test setup before invoking this rule, and that it correctly handles date edge cases (e.g., month boundaries, year transitions).e2etests/testcases/Validate that search work items by labels is filtering correctly.txt (2)
21-21: Verify the intent of double-click action.Line 21 uses
double clickto navigate to the project. Typical UI navigation uses single clicks. Verify this is intentional (e.g., for edit mode) or should be changed to a single click.
18-20: Verify UI element identifiers.Lines 18-20 reference UI elements by identifier names (
"move-right","list-filter","Label"). Confirm these identifiers match the actual UI elements in the Plane application to ensure the test remains resilient across UI updates.e2etests/rules/delete work item "workItem" from project "projectName".txt (1)
1-7: LGTM!Clean deletion flow with proper verification. The double-click confirmation (lines 4-5) is a defensive pattern that aligns with destructive operations. Navigation context is properly maintained.
e2etests/rules/create work item "workItem" on project "projectName".txt (1)
1-7: LGTM!Well-structured creation rule with proper verification check on line 6. This pattern (navigate → add → fill → save → verify → return) provides good coverage and should be the template for other entity creation rules.
e2etests/testcases/Create a view, add work items then drag them.txt (1)
3-9: Test flow and cleanup look good.The view and work item setup is clear, the drag test is focused, and the assertion correctly validates the drag order. The cleanup removes all created entities to prevent state pollution.
e2etests/testcases/Validate that quicklinks redirect to the specified page.txt (1)
9-11: Verify URL assertion is robust and review tab handling.Line 10 asserts the URL matches the stored value. Ensure this check works reliably across browsers (some may normalize URLs). Line 11 correctly switches back to tab 1 for cleanup; this is good multi-window test design.
e2etests/rules/remove cycle "cycleName" from project "projectName".txt (1)
1-7: Clean and consistent reusable rule.The cycle deletion rule follows established patterns with clear navigation, double-confirmation deletion, and verification. Line 7 returns to project context appropriately for subsequent test steps.
e2etests/testcases/Comment on a work item, validate that other users receive notifications on their inbox.txt (2)
9-10: Verify mention syntax is correct for the application.Line 9 uses
"@${projectUser}"to mention another user. Confirm that testRigor's parameter substitution produces the exact mention format expected by the Plane application (e.g.,@usernamewith proper delimiter).
5-15: Multi-user notification flow is well-structured.The logout/login sequences properly isolate user contexts, and the inbox notification check correctly validates the mention count. This effectively tests cross-user notifications.
e2etests/rules/delete page "pageName" from "projectName".txt (1)
1-10: Clean two-step deletion pattern.The rule correctly implements page deletion via archive + delete workflow, which aligns with safety practices. Navigation and cleanup are consistent with other delete operations.
e2etests/rules/create user "user" then join workplace.txt (1)
1-13: Clean and reusable user onboarding rule.The user creation flow is well-designed with parameter-driven email generation (allowing reuse with different users) and appropriate form field handling. The final assertion confirms successful login to the workplace. No issues identified.
e2etests/testcases/Create a work cycle, add work items, validate that progress is being tracked after work items are tagged as completed.txt (2)
9-9: Verify progress assertion text matches UI exactly.Lines 9 and 15 have different assertion wording:
- Line 9:
"1/2 work item closed"(singular)- Line 15:
"2/2 work items closed"(plural)Confirm whether the Plane UI actually renders these exactly as specified. If the UI consistently uses one form (e.g., always plural), one of these assertions will fail.
Also applies to: 15-15
11-11: Consider storing work item name as a value or using parameterized reference.Line 11 references
"workItem2"as a literal string, but lines 6–7 use the stored names from quick add operations. For consistency and clarity, either: (1) confirm the literal "workItem2" matches the added work item name exactly, or (2) store and reuse the work item name value throughout the test.e2etests/testcases/Create a page, validate that other users can modify it.txt (1)
5-17: Well-designed multi-user collaboration test with proper eventual consistency handling.The test correctly validates that page edits by one user persist and are visible to others. The reload operations (lines 9 and 16) appropriately handle eventual consistency in collaborative editing. The logout/login sequences properly isolate user contexts for multi-user validation.
.github/workflows/tR-ci.yml (1)
16-29: Good shell verification for testrigor-cli installation.The installation verification script properly checks for command availability and version. This defensive approach helps catch installation failures early.
e2etests/testcases/Create an active cycle, check that you cant have more than one active cycle.txt (1)
14-16: Verify test logic for cycle state transitions.The test navigates to "Completed cycle" to remove Cycle 1, but Cycle 1 was created with today's date (Line 9). An active cycle (start date today, no end date) should not appear in the "Completed cycles" view. According to the cycle management logic, only cycles with
end_date < now()are eligible for operations like transfer or removal.Verify that:
- Cycle 1 actually transitions to "Completed" status after creation and validation, or
- The test should navigate to "Active cycles" instead, or
- The test setup creates Cycle 1 with a past date instead of today.
This test flow needs clarification to ensure it validates the intended single-active-cycle constraint correctly.
e2etests/testcases/Change view to board, verify that dragging items to other columns updates their status.txt (1)
3-7: Test case validates drag-and-drop status update correctly.The test creates a work item, switches to board view, drags it to "In Progress" column, and asserts the status reflects the change. The flow is logically sound and covers the core functionality described in the PR objective.
e2etests/testcases/Change Project ID, verify that work items get updated accordingly.txt (1)
14-20: Complete the final project ID update with verification.The test updates the project ID back to "E2ETE" (lines 16-20) but does not include navigation cleanup or final assertion to verify the change succeeded. The test ends abruptly without confirming the final state.
Ensure the test includes:
- Verification that the project ID update succeeded (assert "Update project" result or navigate back and confirm), or
- Navigation back to workspace to clean up, or
- Removal of the final update if it's not part of the core test scenario.
e2etests/rules/invite user "userName".txt (1)
1-6: Reusable invite user rule is well-structured.The rule properly parameterizes the userName and constructs an email address using the @test.com domain convention. The flow navigates through the invite UI and returns to workspace. This rule supports the user-management test scenarios in the PR.
e2etests/rules/add view "viewName" to project "projectName".txt (1)
1-7: Well-structured add view rule with proper parameterization.The rule implements a complete create-and-verify flow for adding a view to a project. Stored value usage for projectName and viewName enables reusability across test cases.
e2etests/rules/remove user "userName" from project "projectName".txt (1)
1-10: Comprehensive user removal rule with proper verification.The rule implements a complete remove-and-verify flow with:
- Clear navigation to Members section
- Targeted user row selection in table context
- Two-step removal confirmation
- Post-deletion verification that user is removed
- Proper cleanup navigation
This complements the invite and add user rules to form a complete user-management test suite.
e2etests/rules/delete view "viewName" from project "projectName".txt (1)
1-7: Delete view rule provides complete removal flow with verification.The rule properly implements delete-and-verify for views with two-step confirmation and post-deletion assertion. This rule complements the add view rule to provide complete view management coverage.
e2etests/rules/add user "userName" to project "projectName".txt (1)
1-10: Verify UI selectors match the actual application interface exactly.The rule uses several UI selectors that are context-dependent and could be fragile if the interface changes. Specifically:
- Line 1: Hovering over project name with sidebar context — ensure the context selector "sidebar" is accurate
- Line 2: "Toggle quick actions menu" — confirm this text matches the button's actual label or accessibility name
- Line 6: "Select co-worker" — verify this is the correct label for the dropdown/selector
If the testRigor tests fail with "element not found" errors, review the UI element labels in your Plane instance against these selector values. You may need to inspect the page using testRigor's debugging tools or browser DevTools to confirm the exact text/accessibility attributes.
Also, consider whether the
hoveraction on line 1 is necessary. Some UI interactions may trigger the quick actions menu automatically via click, which could simplify the rule.e2etests/testcases/Add team member to project,assign a work item to them then validate they see the work item.txt (1)
1-5: Clarifysavedvsstoredvalue terminology.Line 1 uses
save "Work item assign test" as "workItem", but line 20 later referencesstored value "workItem". Verify this is intentional:
savedvalues typically persist within the test casestoredvalues typically persist across test runs or from setup/fixturesIf
workItemshould be accessible in cleanup (line 20), ensure you're using the consistent naming convention. If line 1 should usestoreinstead ofsave, update it accordingly.Check your testRigor documentation or syntax rules to confirm the correct keywords for your version. Line 6, 14, and 15 also reference saved value "workItem", so consistency here is important for test reliability.
| with: | ||
| ref: ${{ inputs.refName != '' && inputs.refName || '' }} |
There was a problem hiding this comment.
Fix undefined workflow input refName.
The conditional expression references inputs.refName, but the workflow does not define an inputs object. With workflow_dispatch trigger, you must declare inputs explicitly. The current code will fail when the workflow runs.
Apply this diff to define the input and use it correctly:
on:
push:
branches: [tR-e2e-testing, preview]
pull_request:
branches: [tR-e2e-testing, preview]
workflow_dispatch:
+ inputs:
+ refName:
+ description: 'Git ref (branch/tag/commit) to checkout'
+ required: false
+ default: ''
jobs:
e2e-tests-tR:
runs-on: ubuntu-24.04
steps:
- name: Set up plane
run: |
curl -fsSL https://prime.plane.so/install/ | sh -s -- --silent --domain=127.0.0.1
- name: Install testRigor command line tool
run: |
set -e
echo "Installing testrigor-cli..."
npm install -g testrigor-cli
echo "Verifying testrigor-cli installation..."
if command -v testrigor >/dev/null 2>&1; then
echo "SUCCESS: testrigor-cli is installed"
testrigor --version
else
echo "ERROR: testrigor-cli installation failed"
exit 1
fi
- uses: 'actions/checkout@v4'
name: 'Checkout'
with:
ref: ${{ inputs.refName || '' }}This ensures the input is declared when the workflow is manually triggered and safely defaults to the default branch if not provided.
Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 actionlint (1.7.8)
33-33: property "refname" is not defined in object type {}
(expression)
33-33: property "refname" is not defined in object type {}
(expression)
🤖 Prompt for AI Agents
.github/workflows/tR-ci.yml lines 32-33: the workflow uses inputs.refName but no
workflow_dispatch inputs are declared; add a workflow_dispatch block that
defines an input named refName with a description and default '' (so the input
exists when manually triggered), and then keep or adjust the call site to read
that input (e.g., using the existing conditional expression or replace with a
safer fallback like using github.ref when inputs.refName is empty). Ensure the
inputs block is placed under the workflow trigger section so the workflow no
longer references an undefined input.
| enter string with parameters "${user}@test.com" into "Email" | ||
| check that button "Continue" is enabled | ||
| click "Continue" | ||
| enter "safePassword14*" into "Password" | ||
| check that button "Go to workspace" is enabled | ||
| click "Go to workspace" |
There was a problem hiding this comment.
CRITICAL: Remove hardcoded password from repository.
Line 4 contains a hardcoded password "safePassword14*" that will be committed to the repository and visible to all users with access. This is a security violation even for test credentials.
Recommended fix: Parameterize the password using a stored value or environment variable:
enter string with parameters "${user}@test.com" into "Email"
check that button "Continue" is enabled
click "Continue"
-enter "safePassword14*" into "Password"
+enter stored value "testPassword" into "Password"
check that button "Go to workspace" is enabled
click "Go to workspace"Ensure testPassword is initialized from a secure configuration source (environment variable, secrets manager) in your test setup, not committed to the repository.
Secondary note: Standardize file naming—use lowercase "Log "user" to website.txt" for consistency with "log out.txt".
🤖 Prompt for AI Agents
In e2etests/rules/Log "user" to website.txt around lines 1 to 6, line 4 contains
a hardcoded password "safePassword14*" which must be removed; replace the
literal with a parameter (e.g., testPassword) sourced from a secure
configuration (environment variable or secrets manager) initialized in the test
setup, and update the test to use that variable when entering the password; also
rename the file to lowercase (log "user" to website.txt) for naming consistency.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove or explain duplicate login.
Lines 2-3 both execute Log stored value "adminUser" to website, which appears to be a duplicate login attempt for the admin user. This is likely unintended.
Either:
- Remove line 3 if the duplicate is unnecessary
- Add a comment explaining why two logins are needed (e.g., if the first login can time out)
save "Work item assign test" as "workItem"
Log stored value "adminUser" to website
- Log stored value "adminUser" to website
add user stored value "invitedUser" to project stored value "projectName"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| save "Work item assign test" as "workItem" | |
| Log stored value "adminUser" to website | |
| add user stored value "invitedUser" to project stored value "projectName" |
🤖 Prompt for AI Agents
In e2etests/testcases/Add team member to project,assign a work item to them then
validate they see the work item.txt around lines 2-3, there are two identical
steps "Log stored value \"adminUser\" to website" which appears to be a
duplicate login; remove the second occurrence if it's unnecessary, or replace it
with a brief inline comment explaining why a second login is required (for
example to refresh session or simulate re-login) so the intent is clear.
| click saved value "workItem" | ||
| click "Add assignees" | ||
| click stored value "invitedUser" | ||
| click "E2E Testing playground" below "Projects" within the context of "sidebar" |
There was a problem hiding this comment.
Resolve hardcoded project name on line 9.
Line 9 hardcodes "E2E Testing playground" as the project name when navigating back to workspace, but line 12 (after login as invited user) correctly uses stored value "projectName" to navigate to the project.
For test reusability and maintainability, line 9 should reference the same project:
- click "E2E Testing playground" below "Projects" within the context of "sidebar"
+ click stored value "projectName" below "Projects" within the context of "sidebar"This ensures the test can run in different project contexts without modification.
Also applies to: 12-12
🤖 Prompt for AI Agents
e2etests/testcases/Add team member to project,assign a work item to them then
validate they see the work item.txt around line 9 (also applies to line 12): the
test currently hardcodes the project label "E2E Testing playground" when
clicking the project in the sidebar; change the step to use the stored value
"projectName" instead of the literal string so the click targets the dynamic
project name (and update the similar occurrence at line 12) — replace the
hardcoded locator text with a reference to stored value "projectName" so the
test uses the runtime project name for navigation.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate logging statement.
Consistent duplication pattern across all test cases.
Log stored value "adminUser" to website
-Log stored value "adminUser" to website
create work item "workItem" on project stored value "projectName"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| create work item "workItem" on project stored value "projectName" |
🤖 Prompt for AI Agents
In e2etests/testcases/Change Project ID, verify that work items get updated
accordingly.txt around lines 1 to 2, there is a duplicated logging statement
"Log stored value \"adminUser\" to website"; remove the redundant duplicate so
only a single log call remains, and ensure any surrounding test flow or
assertions still reference the one remaining log entry.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate admin user login statements.
Lines 1–2 both log the stored adminUser value to the website, which appears to be redundant. This pattern is repeated across multiple test files and suggests a copy-paste artifact from a shared template.
-Log stored value "adminUser" to website
-Log stored value "adminUser" to website
+Log stored value "adminUser" to websiteIf the double login is intentional (e.g., as a workaround for test fixture timing), please add a comment explaining why.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website |
🤖 Prompt for AI Agents
In e2etests/testcases/Create a view, add work items then drag them.txt around
lines 1 to 2, there are duplicate statements that log the stored "adminUser"
value to the website; remove the redundant second logging call (or keep one) so
the adminUser is only logged once, and if the duplication was intentional for
timing/workaround, replace the duplicate with a brief comment explaining the
reason.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate admin user login statements.
Lines 1–2 duplicate the login sequence, consistent with other test files.
-Log stored value "adminUser" to website
-Log stored value "adminUser" to website
+Log stored value "adminUser" to website📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website |
🤖 Prompt for AI Agents
In e2etests/testcases/Create a work cycle, add work items, validate that
progress is being tracked after work items are tagged as completed.txt around
lines 1 to 2, there are duplicate "Log stored value 'adminUser' to website"
statements; remove the redundant second occurrence so only one login/log
statement remains (keeping the single correct placement consistent with other
test files) and run the tests to verify no regressions.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate logging statement.
Line 1 and Line 2 are identical and redundant. This appears to be unintended duplication from copy-paste.
Log stored value "adminUser" to website
-Log stored value "adminUser" to website
add a cycle "Cycle 1" to project stored value "projectName"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website |
🤖 Prompt for AI Agents
In e2etests/testcases/Create an active cycle, check that you cant have more than
one active cycle.txt around lines 1-2 there are two identical "Log stored value
"adminUser" to website" statements; remove the duplicate so only one logging
call remains (delete either line 1 or line 2) to eliminate the redundant
copy-paste entry.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate admin user login statements.
Same issue as the previous test file. Lines 1–2 duplicate the login sequence.
-Log stored value "adminUser" to website
-Log stored value "adminUser" to website
+Log stored value "adminUser" to website📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website |
🤖 Prompt for AI Agents
In e2etests/testcases/Validate that quicklinks redirect to the specified
page.txt lines 1-2, the test contains duplicate "Log stored value 'adminUser' to
website" login statements; remove the redundant second occurrence so the login
sequence appears only once, ensuring any subsequent steps still refer to the
single logged-in state.
| Log stored value "adminUser" to website | ||
| Log stored value "adminUser" to website |
There was a problem hiding this comment.
Remove duplicate login step.
Lines 1 and 2 are identical, logging in the same user twice. This appears to be a copy-paste error that should be removed to avoid unnecessary test execution overhead.
Apply this diff:
Log stored value "adminUser" to website
-Log stored value "adminUser" to website
save "Work item to label" as "workItem"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| Log stored value "adminUser" to website | |
| save "Work item to label" as "workItem" |
🤖 Prompt for AI Agents
In e2etests/testcases/Validate that search work items by labels is filtering
correctly.txt around lines 1-2, there is a duplicated step "Log stored value
\"adminUser\" to website" executed twice; remove the redundant second occurrence
so the test logs in the admin user only once, leaving a single login step to
avoid unnecessary duplicate execution.
1 participant
This is a re-submission of this PR
as it wasn't properly rebased.
This pull request adds end-to-end test cases using testRigor.
testRigor is an AI-powered end-to-end testing platform that allows you to write tests in plain English. This setup enables automated testing of the Plane application's user interface and functionality from a user's perspective.
Here are the results of the latest test suite run: https://app.testrigor.com/public/RMEFLdnHwGbLu265M
Why testRigor?
Test cases written in plain English: Anyone can contribute automated tests without any language-specific coding skills, broadening the contributor base and allowing a higher test coverage.
Reduced maintenance overhead: Tests are resilient to UI changes, lowering the cost of keeping the suite up to date.
Cross-platform coverage: Support across different environments and setups such as mobile, desktop and web.
How to test the changes in this Pull Request:
There are 2 ways to test these changes, either by triggering the workflow actions or by executing it manually:
Workflow actions:
Type of Change
Test Scenarios:
For the test cases being executed, the test scenario consists in a regular self-hosted plane instance (installed following these rules) that includes 1 admin and 2 normal users.
The 10 test cases being added test, different functionalities these include:
Note
Cursor Bugbot is generating a summary for commit 8d87bb5. Configure here.
Summary by CodeRabbit
Tests
Documentation