Test mode
Test Mode automatically prevents all dangerous actions during your automated tests.
Why test mode matters
When you run a test flow, Flowguard simulates real user actions on your website, like filling out and submitting forms. Without Test Mode, real data gets sent:
- Real emails to customers or employees
- Newsletter subscriptions to external services
- CRM entries in your sales system
- Webhooks to third parties (Zapier, Make, etc.)
- New posts or users in your database
- Payment requests to payment providers
What does test mode do?
Test Mode intercepts all these actions and prevents them automatically:
- No real emails are sent
- No external API calls to newsletter tools, CRMs or webhooks
- No database changes (new posts, pages, users)
- No scheduled tasks are created
- Captchas are automatically bypassed (for smooth testing)
All blocked actions are logged and displayed after each test.
Why is test mode "Recommended"?
Test Mode is enabled by default because:
- Protection from real submissions: You can test safely without accidentally sending real emails
- No duplicates: Prevents test contacts in your CRM or newsletter tool
- Clean database: No test entries in your live database
- Saves costs: No accidental API calls that could incur costs
- Professional: Customers don't receive test emails with "Test 123" content
Recommendation
Keep Test Mode always enabled unless you consciously want to send real data in a live test.
Configure settings
Where do I find test mode settings?
WordPress Admin > Flowguard > Settings > Testing Tab
Available options
1. Enable test mode (main switch)
Status: Recommended: Enabled
- Enabled: All test flows are protected, no real actions are executed
- Disabled: WARNING - Flows will execute real actions!
2. Email handling (email strategy)
Choose how emails are handled in Test Mode:
Option A: Block all emails (Default)
What happens:
- Emails are completely blocked and not sent
- All details are logged (recipient, subject, CC, BCC)
- No mailbox is burdened
When to use:
- For most tests (default recommendation)
- When you only want to test if the form works
- When you don't want test emails in your mailbox
Option B: Redirect to test email
What happens:
- All emails are redirected to one test email address
- CC and BCC recipients are automatically removed (privacy!)
- You can review the email content
- Original recipient is recorded in the log
When to use:
- When you want to review the email content
- For testing email templates
- When you want to ensure emails actually arrive
Requires:
- Test Email Address - Enter your test email address (e.g.,
tests@yourcompany.com)
3. Test email address (only for "Redirect")
Example: flowguard-test@yourcompany.com
- All test emails will be sent to this address
- It's best to use a dedicated test address
- Do NOT use a real customer email address
What gets blocked?
1. Emails
Blocked:
- Contact form notifications
- Order confirmations
- Newsletter confirmations
- Admin notifications
- All emails via
wp_mail()
Details in log:
- To
- Subject
- CC recipients (if present)
- BCC recipients (if present)
- Redirect (in "Redirect" mode)
2. External HTTP requests
Blocked:
- Newsletter subscriptions (Mailchimp, Sendinblue, etc.)
- CRM integrations (HubSpot, Salesforce, etc.)
- Webhooks (Zapier, Make, n8n, etc.)
- Analytics tracking
- Social media APIs
- Payment APIs (Stripe, PayPal, etc.)
Allowed: (not blocked)
- Requests to your own WordPress site
- Requests to localhost (for development)
Details in log:
- Host (e.g., api.mailchimp.com)
- URL
- Method (GET, POST, etc.)
- Purpose (Newsletter, CRM, Webhook, etc.)
3. Database changes
How it works: Test Mode uses a "False Positive" strategy. Forms think they succeeded, but nothing is actually saved.
Blocked (with fake success):
- New posts - Returns fake post ID (e.g.,
-12345) - New pages - Returns fake post ID
- New users - Returns fake user ID (e.g.,
-56789) - Post metadata
- User metadata
- WordPress options (
update_option,add_option,delete_option)
Why "fake success"?
- Forms submit successfully (no error messages)
- Success pages display normally
- Flows complete without failing
- BUT: No real data is created!
Allowed: (not blocked)
- Flowguard's own data (flow results, logs, settings)
- WordPress core functions (cron, transients)
- Temporary data (transients)
4. Scheduled tasks
Blocked:
- WP-Cron events
- Action Scheduler tasks
- Delayed emails
- Automatic backups (triggered by tests)
5. Captchas and anti-spam
Automatically bypassed:
- Google reCAPTCHA (v2 & v3)
- hCaptcha
- Cloudflare Turnstile
- CaptchaFox
- Akismet Anti-Spam
How it works: Flowguard intercepts the server-side captcha verification requests and returns valid success responses. For reCAPTCHA v3, a high trust score (0.9) is included. Additionally, plugin-specific validation filters clear any remaining captcha errors.
Why: So your automated tests run smoothly
6. Supported form plugins
Test Mode has built-in support for these form plugins with plugin-specific interception:
| Plugin | Captcha Bypass | Entry Blocking | Email Blocking | Spam Bypass |
|---|---|---|---|---|
| WPForms | ✅ | ✅ | ✅ | ✅ |
| Contact Form 7 | ✅ | ✅ | ✅ | ✅ |
| Gravity Forms | ✅ | ✅ | ✅ | ✅ |
| WS Form | ✅ | ✅ | ✅ | ✅ |
All other form plugins are also protected through the generic interception layers (email blocking via wp_mail, HTTP request blocking, and database write prevention). The plugins listed above have additional, plugin-specific hooks for better compatibility.
Test mode in the Flow Editor
Automatic protection in the editor
Test Mode is active in the Flow Editor!
- The Flow Editor activates Test Mode automatically (when enabled in settings)
- Form submissions in the editor are protected
- Emails are blocked/redirected
- External API calls are prevented
How does it work?
Technical approach: Query Parameter Injection
- The editor adds
?flowguard_preview=1to all URLs in the iframe - This parameter is automatically maintained across all navigations:
- Link clicks
- Form submissions
- JavaScript redirects
- Browser history changes
- WordPress detects this parameter and activates Test Mode
- The parameter is visually hidden, you won't see it in the URL bar
- The parameter is filtered from recordings, your saved flows contain clean URLs
When is test mode active?
Test Mode is active in TWO scenarios:
- Flow Editor (with settings enabled)
- While browsing in the editor iframe
- Automatically for all navigations
- Automated Flow Runs
- When you click "Run Flow"
- Throughout the entire flow execution
- All blocked actions displayed in logs
Test Mode is NOT active:
- In normal frontend browsing (outside editor)
- If Test Mode is disabled in settings
View test logs
After each flow run, you can see exactly what was blocked:
Where do I find the logs?
- Go to Flowguard > Flows
- Find the flow with a completed run
- Click "View Log"
What do the logs show?
In the header:
- Number of steps
- Number of successful steps
- Number of failed steps
- Number of blocked actions (orange)
In the timeline:
- All executed steps (green = successful, red = failed)
- Blocked actions (orange) with details:
- Email Blocked: Which email was blocked
- Email Redirected: Where it was redirected to
- HTTP Request Blocked: Which external service was blocked
- Database Write Prevented: What was not written to the DB
- Cron Job Prevented: Which scheduled task was prevented
Frequently asked questions (FAQ)
Q: Do I have to activate test mode for each flow individually?
A: No. Test Mode is a global setting and automatically applies to all flows.
Q: Can I disable test mode for specific flows?
A: Currently, there is only a global setting. If you want to run a "real" test, temporarily disable Test Mode in the settings.
Q: Do my tests become slower with test mode?
A: No. Test Mode actually makes tests faster because external API calls are blocked immediately (no waiting for timeouts).
Q: What happens if I disable test mode?
A: All flows will then execute real actions:
- Real emails will be sent
- Real data will be transmitted to external systems
- Real entries in the database
WARNING
Only disable for deliberate live tests!
Q: Does test mode work with WooCommerce?
A: Yes. Orders are not created, order emails are blocked, and payment APIs are not called. See the WooCommerce Testing Guide for details.
Q: What if a plugin uses custom email functions?
A: Test Mode intercepts all emails that run through WordPress' wp_mail() function. Most plugins use this. In rare cases (direct SMTP connection), an email might get through.
Best practices
DO (Recommended approach)
- Always keep Test Mode enabled for normal tests
- Use "Redirect to test email" when you want to check email content
- Review test logs regularly to see what was blocked
- Use a dedicated test email address (not your main address)
- Briefly disable Test Mode only for deliberate live tests (and immediately re-enable it afterwards!)
DON'T (Avoid)
- Don't disable Test Mode permanently - Risk of accidental live actions!
- Don't use real customer emails as test address
- Don't test without Test Mode in the development environment
- Don't assume that emails aren't arriving, check the logs!
Limitations: third-party payment windows
Some payment integrations (PayPal, Stripe Checkout, etc.) open an external popup window or redirect to a third-party domain for payment processing. Flowguard cannot interact with these external windows because they run on a different domain outside of your WordPress site.
What Flowguard does
- Blocks all outgoing payment API calls , requests to PayPal, Stripe, Square, Braintree, and other payment services are intercepted and blocked during Test Mode
- Fakes the form submission, the form thinks the submission succeeded, even though no payment was processed
- No real money is ever charged during a test
What Flowguard cannot do
- Click buttons inside PayPal/Stripe popups, these windows are on external domains that Flowguard has no control over
- Follow redirects to payment pages, if a form redirects to
paypal.comorcheckout.stripe.com, the test cannot continue on that page
Best practice for payment forms
Instead of testing the full payment flow, test up to the payment step:
- Fill out the form as usual (name, email, address, etc.)
- Assert that the payment button is visible (e.g., "Pay with PayPal" button)
- Do NOT click the payment button in your flow, stop the test here
This confirms that your form, validation, and layout work correctly. The payment gateway itself is the responsibility of PayPal/Stripe, not your site.
Example Flow for a Payment Form
- Navigate to your form page
- Fill in all required fields
- Assert: Payment button is visible
- Assert: No form validation errors shown
This is the recommended pattern used by all major E2E testing platforms.
WooCommerce exception
For WooCommerce checkouts, Flowguard provides the Flowguard Test Payment Gateway, a special payment method that simulates a successful payment without any external redirects. This lets you test the complete checkout flow end-to-end. See WooCommerce Testing for details.
SureCart exception
For SureCart checkouts, Flowguard automatically forces SureCart into test mode during test runs. This means SureCart uses its own sandbox environment, so no real payments are processed and no real orders are created. See SureCart Testing for details.
Related documentation
- Settings - Configure all Flowguard settings
- WooCommerce Testing - Safe WooCommerce checkout testing
- Running Flows - How flow execution works