Testing Rules

The Test tab lets you run a rule against sample data and see exactly what it does — before you activate it. This is the single best habit you can build with rules: never activate a rule you haven’t tested.

Two panes: Test Data on the left (the input), Rule Execution on the right (what happens when you run it).

Loading test data

The Test Data pane has three modes, picked from the tabs at the top:

• Search — find a real recent record from your store by ID, customer name, or email. Use this when you have a known case the rule should (or shouldn’t) handle.
• Suggest — DropStream picks a representative record for you. Useful when you just want a working example without thinking about which one.
• Generate — produces synthetic test data on demand. Pick the number of items you want and click Generate Order (or the equivalent for your hook). Useful when no real data fits, or when you want a clean slate.

Once data loads, the Test Data pane becomes a property editor — you can edit any field before running. There’s also a JSON view (the </> icon) if you’d rather see the whole record as raw JSON.

Running the rule

Click Execute. The Rule Execution pane fills with the result.

The default view is Changes Made by Rule — every field the rule modified, with the new value. Toggle Changed / All to see the changed fields only or every field on the record.

If nothing happened — no changes appeared, or fewer than you expected — that’s a signal. Either the condition didn’t match the data you loaded, or the actions didn’t write what you expected. Either way, switch on the trace.

Reading the trace

Toggle Trace in the upper right of the Rule Execution pane and click Execute again. The result becomes a step-by-step record of what the rule did:

The trace shows:

• Stats at the top — how long the rule took, how many conditions were evaluated, how many fields were modified, how many actions ran.
• Condition Flow — every condition the rule checked, with a green checkmark if it matched and a red X if it didn’t. The actual values used in the comparison are shown so you can see why a condition matched (or didn’t).
• Assignments — every value the rule wrote, with the before value (often null for a new record) on the left and the after value on the right.

Debugging a rule that doesn’t fire

If the Changes view is empty or smaller than expected:

1. Switch on the trace. It will tell you which conditions failed and what values they saw.
2. Look at the failed condition. The trace shows the field’s actual value. Often the problem is a typo in the field name, a value that didn’t match exactly ("UPS" vs "ups"), or a field that’s null when you expected a value.
3. Edit the test data. The Test Data pane is editable — change a field and re-run. Faster than going back to the source data and re-importing.
4. Or edit the rule. If the trace shows the rule’s logic is wrong, switch to Visual or Code, fix it, come back to Test, and run again.

Code view

Toggle Code to see the BGL of the rule that just ran. Useful when you’re learning the language — you can see exactly what the visual editor produced, side by side with the trace of how it executed.

Why this matters

Rules run automatically on production data. A rule that does the wrong thing can affect thousands of orders before anyone notices. The Test tab exists so that “did I get this right?” has a fast, repeatable answer — and so you never need to find out from a customer.

New rules start inactive. Activate them only after you’ve run them in Test against representative data and confirmed the behavior matches your intent.