Testing Sandbox
The Testing Sandbox lets you simulate rule execution before it affects real members. This safety feature helps you build confidence in your automation and catch mistakes early.
Why Testing Matters
Rules can affect hundreds or thousands of members instantly. A misconfigured rule might:
- Add wrong roles to everyone
- Remove important roles accidentally
- Trigger cascading effects you didn't anticipate
The sandbox eliminates this risk by letting you see what would happen without actually changing anything.
Accessing the Sandbox
- Open the Rule Editor for any rule
- Look for the "Test" tab or section
- You're now in the sandbox environment
How to Test Rules
Step 1: Select Test Roles
The sandbox shows a list of all roles in your server. Select the roles you want to simulate a member having.
Example: To test what happens when a member has "Verified" and "Level 5":
- Click "Verified" to select it
- Click "Level 5" to select it
- These are now the "test member's" roles
Step 2: Run the Test
Click "Run Test" to simulate rule execution.
Step 3: Review Results
The sandbox shows you:
- Roles that would be added: Green or highlighted list
- Roles that would be removed: Red or highlighted list
- Rules that would trigger: Which rules matched and in what order
Step 4: Iterate
Adjust your test roles and run again to explore different scenarios.
Testing Strategies
Test Common Scenarios
Think about typical members and test their role combinations:
- New member with no roles
- Verified member with basic roles
- VIP member with premium roles
- Staff member with moderation roles
Test Edge Cases
Consider unusual situations:
- Member with all roles selected
- Member with conflicting roles
- Member with only @everyone
Test the @everyone Role
Always include @everyone in your tests! Every Discord member has this role, and rules using "Lacks" conditions might behave unexpectedly if you forget it.
Test High-Population Roles
Before going live, specifically test with roles that many members have:
- Your main "Member" or "Verified" role
- The @everyone role
- Any role with 100+ members
If a rule incorrectly matches these roles, it could affect a large portion of your server.
Understanding Test Results
"Roles Added" Section
Lists all roles that would be assigned to a member with the selected roles. These are the positive changes your rules would make.
"Roles Removed" Section
Lists all roles that would be taken away from a member with the selected roles. Review carefully to ensure you're not removing important roles.
"Rules Triggered" Section
Shows which rules matched the test criteria and in what order. This helps you understand rule cascading:
- Rule "Auto-VIP" triggered first (priority 0)
- Rule "VIP Cleanup" triggered second (priority 1)
- ... and so on
No Changes
If no rules matched, you'll see a message indicating no changes would occur. This might mean:
- Your conditions don't match the test roles
- You need to add different test roles
- The rule is working correctly by not matching
Testing Cascading Rules
The sandbox accurately simulates rule cascading:
- You select initial roles
- Rule A triggers and "adds" Role X
- The sandbox then checks if Role X triggers Rule B
- Rule B triggers and "adds" Role Y
- Continue until no more rules match
The results show the final state after all cascades complete.
Testing Specific Rules vs. All Rules
Test All Rules (Default)
The standard test runs all enabled rules against your test roles. This shows the complete picture of what would happen.
Focus on One Rule
To understand a specific rule's behavior:
- Temporarily disable other rules
- Run your test
- Re-enable rules when done
Or mentally filter the results to focus on the rule you're investigating.
Common Testing Mistakes
Forgetting @everyone
The @everyone role is implicit—every member has it. If your rules use "Lacks All Roles" or similar conditions, @everyone might prevent matches.
Fix: Always include @everyone in your test selections.
Not Testing Cascades
Testing only the initial trigger misses cascading effects. A rule might add a role that triggers another rule.
Fix: Review the "Rules Triggered" section to see the full chain.
Testing Only Happy Paths
It's easy to test the expected scenarios and miss edge cases.
Fix: Deliberately test unexpected combinations—members with conflicting roles, members with everything, members with nothing.
Not Retesting After Changes
After modifying a rule, old test results are invalid.
Fix: Re-run tests after every change to verify behavior.
Tips for Effective Testing
Create a Test Checklist
Before going live with new rules, test:
- New member (no roles except @everyone)
- Verified member (basic expected roles)
- The specific scenario this rule is for
- Edge cases (conflicting roles, etc.)
- High-population roles (to avoid mass changes)
Test Incrementally
When building complex rules:
- Create the first condition, test it
- Add the action, test it
- Add additional conditions, test each
- Add priority, test with other rules
- Enable and monitor
Document Expected Results
Before running a test, write down what you expect to happen. Compare with actual results to catch surprises.
Use Sandbox Before Every Go-Live
Make testing a habit. No matter how confident you are, a quick sandbox run takes seconds and can save hours of cleanup.
Limitations
Sandbox Doesn't Test Permissions
The sandbox checks rule logic but doesn't verify:
- Role hierarchy issues
- Missing "Manage Roles" permission
- Cross-server permissions
These must be verified separately or will show as errors in production.
Sandbox Is Instant
Real rule execution has slight latency due to Discord API calls. The sandbox shows instant results that don't reflect actual timing.
Sandbox Uses Current Rules
The sandbox tests rules as they currently exist. If you have unsaved changes, save them first to test the new version.
Next Steps
- Troubleshooting — Solve problems when rules don't work as expected
- Best Practices — Build reliable automation
- Common Scenarios — See tested patterns you can adapt