# Testing Rules

Testing rules before deploying to production prevents bugs and ensures field behavior works as expected. This guide provides a practical testing workflow and checklist.

***

## Testing Workflow

Follow this five-step process for each rule:

### 1. Create Rule with Specific Conditions

**Setup:**

* Create rule in test project or sandbox first
* Use specific, testable conditions
* Keep initial rule simple (add complexity after basic test passes)

**Example:**

```
Rule: Show Root Cause for High Priority Bugs
- Screen: Global Issue Create
- Target Field: Root Cause
- Scope: Bug
- Condition: Priority = High
- Action: Show field
```

***

### 2. Test with Matching Context

**Verify rule applies when it should:**

**Test case:** Create Bug with Priority = High

* ✅ Expected: Root Cause field appears
* ✅ Verify: Field is visible
* ✅ Check: Action applied correctly

**What to test:**

* Correct screen (Create/View/Transition)
* Correct project
* Correct issue type (scope)
* Correct field value (condition)
* Correct user role (if user-based condition)

**Testing checklist:**

* ☐ Open correct screen (Create issue dialog, Issue View, Transition)
* ☐ Select issue type matching scope
* ☐ Set field values to match conditions
* ☐ Verify action executes (field shows/hides/locks/sets value)
* ☐ Test as correct user role (if applicable)

***

### 3. Test with Non-Matching Context

**Verify rule doesn't apply when it shouldn't:**

**Test cases:**

* Create Bug with Priority = Low → Root Cause should NOT appear
* Create Story with Priority = High → Root Cause should NOT appear (wrong scope)
* View existing Bug (wrong screen) → Rule doesn't apply

**What to test:**

* Wrong issue type (outside scope)
* Wrong field value (condition not met)
* Wrong screen (rule configured for different screen)
* Wrong user role (if user-based condition)

**Testing checklist:**

* ☐ Test with issue type outside scope
* ☐ Test with field values not matching condition
* ☐ Test on different screen (if rule is screen-specific)
* ☐ Verify rule does NOT apply
* ☐ Test as different user role (if applicable)

***

### 4. Test Edge Cases

**Test unusual or boundary conditions:**

**Common edge cases:**

* **Empty values:** Field has no value (null, undefined)
* **Special characters:** Field contains quotes, commas, special symbols
* **Boundary values:** Numeric thresholds (exactly $10,000, not just over/under)
* **Multiple selections:** Multi-select fields with various combinations
* **Long text:** Fields with very long content

**Example edge cases:**

```
Condition: Estimated Cost > 10000

Edge cases to test:
- Cost = 10000 (exactly at boundary - should NOT trigger)
- Cost = 10001 (just over boundary - should trigger)
- Cost = 9999 (just under boundary - should NOT trigger)
- Cost = empty (no value - should NOT trigger)
- Cost = 0 (zero - should NOT trigger)
- Cost = negative value (if possible - handle appropriately)
```

**Testing checklist:**

* ☐ Test with empty/null field values
* ☐ Test exact boundary values for numeric conditions
* ☐ Test with special characters if field is text
* ☐ Test with very long text if field is text
* ☐ Test all combinations for multi-select fields

***

### 5. Test Interactions

**Test how rule interacts with other rules:**

**Scenarios to test:**

* **Multiple rules on same field:** Do they conflict or complement?
* **Sequential rules:** Rule A shows field, Rule B requires it
* **Conditional dependencies:** Rule depends on field affected by another rule

**Example interaction test:**

```
Rule 1: Show Root Cause when Priority = High
Rule 2: Require Root Cause when Priority = Critical

Test cases:
- Priority = High → Root Cause shows, not required (Rule 1 only)
- Priority = Critical → Root Cause shows AND required (both rules)
- Priority = Low → Root Cause hidden (neither rule)
```

**Testing checklist:**

* ☐ Identify all rules affecting same field
* ☐ Test with only first rule enabled
* ☐ Test with both rules enabled
* ☐ Verify no conflicts (both rules work together)
* ☐ Check for "hidden required" trap (required field that can be hidden)

***

## Testing Checklist Template

Use this checklist for each new rule:

**Pre-deployment testing:**

* ☐ Rule enabled in test/sandbox project
* ☐ Tested with matching conditions (rule applies)
* ☐ Tested with non-matching conditions (rule doesn't apply)
* ☐ Tested edge cases (empty, boundary, special values)
* ☐ Tested interactions with other rules
* ☐ Tested with different user roles (if user-based)
* ☐ Tested on correct screen (Create/View/Transition)
* ☐ Verified no console errors (check browser dev tools)

**Post-deployment verification:**

* ☐ Deployed to production
* ☐ Tested by actual users (not just admin)
* ☐ Monitored for support tickets or confusion
* ☐ Verified performance (no slowdown)

***

## Testing by Rule Type

### Show/Hide Field Rules

**Test:**

* ✅ Field appears when condition met
* ✅ Field disappears when condition changes
* ✅ Hidden field retains value if user filled it (Create screen)
* ✅ Field doesn't show for wrong issue types

***

### Make Field Required Rules

**Test:**

* ✅ Red asterisk appears when condition met
* ✅ Form won't submit without filling field
* ✅ Field is visible (can't require hidden field)
* ✅ Validation works on correct screen (not supported on Issue View)

***

### Lock Field Rules

**Test:**

* ✅ Field becomes read-only when condition met
* ✅ User cannot edit locked field
* ✅ Empty locked fields are hidden (Issue View behavior)
* ✅ Field unlocks when condition no longer met

***

### Set Field Value Rules

**Test:**

* ✅ Field populates with correct value
* ✅ User can change pre-filled value (if not locked)
* ✅ Smart Values calculate correctly
* ✅ Value persists on form submission

***

### Limit Field Options Rules

**Test:**

* ✅ Only specified options appear in dropdown
* ✅ Hidden options are not selectable
* ✅ Previously selected hidden option remains (if already set)
* ✅ Options revert when condition changes

***

## Testing Tools

### Browser Developer Tools

**Check for errors:**

* Open browser console (F12)
* Look for JavaScript errors
* Check network tab for failed requests

**Useful for:**

* Debugging why rule isn't applying
* Seeing API errors from Dynamic Screen Rules
* Verifying UI Modifications loaded

***

### Test Projects and Sandboxes

**Best practice:** Test in non-production environment first

**Options:**

* Create test project in production Jira
* Use Jira sandbox (separate instance)
* Test with test user accounts (different permissions)

**Benefits:**

* Safe to experiment
* Can test destructive changes
* No impact on real work

***

### Test User Accounts

**Create test users with different permissions:**

* Regular user (no special permissions)
* Project admin
* User in specific groups (Finance, Managers, etc.)
* External user (if applicable)

**Test user-based rules:**

* Verify rules show/hide for correct groups
* Confirm role-based conditions work
* Check permission-based rules

***

## Common Testing Mistakes

### Not Testing as Real Users

**Mistake:** Only testing as admin **Impact:** Rules may not work for regular users due to permissions **Solution:** Test with different user roles and permissions

### Testing Only Happy Path

**Mistake:** Only testing when rule should apply **Impact:** Rule may apply incorrectly in other contexts **Solution:** Test both matching and non-matching conditions

### Ignoring Edge Cases

**Mistake:** Not testing boundary values, empty fields, special characters **Impact:** Rules fail in production with unusual data **Solution:** Test edge cases systematically

### Not Testing Interactions

**Mistake:** Testing each rule in isolation **Impact:** Rules conflict when multiple are enabled **Solution:** Test with all related rules enabled

### Deploying Untested Rules

**Mistake:** Creating rules directly in production **Impact:** Bugs affect real users immediately **Solution:** Always test in sandbox or test project first

***

## When to Re-Test

**Re-test rules when:**

* Modifying existing rule (changed conditions or actions)
* Adding new rule affecting same field
* Jira platform updates (major version changes)
* Users report unexpected behavior
* Integrating with new apps (potential conflicts)

**Re-testing workflow:**

1. Disable rule in production
2. Test modified rule in sandbox
3. Verify no regressions
4. Re-enable in production
5. Monitor for issues

***

## Performance Testing

**For large rule sets (50+ rules):**

**Test form load times:**

* Measure: Time from opening form to all modifications applied
* Benchmark: Should be under 1 second
* Monitor: Browser performance tab

**Signs of performance issues:**

* Slow form loading (spinner icon for 2+ seconds)
* Delayed field visibility changes
* Browser becomes unresponsive

**Solutions:**

* Simplify complex conditions
* Reduce number of rules per screen
* See [Performance Considerations](https://teranoapps.gitbook.io/dynamic-screen-rules/best-practices/performance-considerations)

***

## Rollback Plan

**If rule causes problems in production:**

**Immediate action:**

1. Disable problematic rule
2. Verify issue is resolved
3. Communicate to users (if needed)

**Investigation:**

1. Review rule configuration
2. Test in sandbox to reproduce issue
3. Identify root cause
4. Fix and re-test

**Re-deployment:**

1. Test fix in sandbox
2. Re-enable in production
3. Monitor closely for 24 hours

***

## Related Pages

**Design:**

* [Designing Effective Rules](https://teranoapps.gitbook.io/dynamic-screen-rules/best-practices/designing-effective-rules) - Create testable rules

**Organization:**

* [Organizing Rules](https://teranoapps.gitbook.io/dynamic-screen-rules/best-practices/organizing-rules) - Structure rules for easier testing

**Configuration:**

* [Creating Your First Rule](https://teranoapps.gitbook.io/dynamic-screen-rules/configuration-guide/creating-your-first-rule) - Step-by-step creation

**Troubleshooting:**

* [Common Issues](https://github.com/mivchal333/dynamic-screen-rules-docs/blob/main/troubleshooting/common-issues.md) - Debug rule problems
* [Debugging Rules](https://github.com/mivchal333/dynamic-screen-rules-docs/blob/main/troubleshooting/debugging-rules.md) - Systematic debugging

**Performance:**

* [Performance Considerations](https://teranoapps.gitbook.io/dynamic-screen-rules/best-practices/performance-considerations) - Optimize rule sets

Thorough testing prevents bugs and builds confidence in your rule set. Invest time in testing upfront to avoid issues in production.