# How to test a Bubble app in preview mode

- Tool: Bubble
- Difficulty: Beginner
- Time required: 15-20 min
- Compatibility: All Bubble plans
- Last updated: March 2026

## TL;DR

Bubble provides built-in testing tools including Preview mode for interactive testing, the Step-by-step Debugger for inspecting workflow execution, Server Logs for backend monitoring, and the Issue Checker for finding configuration problems. Create test user accounts with different roles to verify permissions, and use test data to exercise all workflows before deploying to live.

## Test Your Bubble App Thoroughly Before Going Live

This tutorial covers all the testing tools Bubble provides and how to use them effectively. You will learn to use the Debugger for step-by-step workflow inspection, Server Logs for backend monitoring, the Issue Checker for catching configuration errors, and strategies for testing with different user roles and data sets.

## Before you start

- A Bubble account with an app that has pages, workflows, and data
- At least one Data Type with sample records
- User authentication set up with at least two roles

## Step-by-step guide

### 1. Use Preview Mode for Interactive Testing

Click the 'Preview' button in the top-right of the editor to open your app in a new tab. This runs the development version of your app where you can interact with it as a user would. Test all user flows: sign up, log in, create records, navigate between pages, and submit forms. Check responsive behavior by resizing the browser window. Preview mode connects to your development database, so any data created here does not affect your live app.

> Pro tip: Use Preview in an incognito window to test as a logged-out user while staying logged in as an editor in your main window.

**Expected result:** You can interact with your app and test all user-facing features in the development environment.

### 2. Enable and Use the Step-by-Step Debugger

In Preview mode, click the 'Debugger' button at the bottom of the page. Enable 'Step-by-step' mode. Now when you trigger a workflow (e.g., click a button), the debugger pauses at each action and shows you: which action is running, what data is being used, and the result of each step. Click 'Next' to advance through each action. This lets you see exactly what happens in your workflows, what values dynamic expressions evaluate to, and where things go wrong.

**Expected result:** You can step through any workflow action by action, inspecting data values at each step.

### 3. Check Server Logs for Backend Issues

Go to the Logs tab in your editor. Server Logs show every workflow execution, API call, and error on the server side. Filter by date range, log level (error, warning, info), and workflow type. Look for red error entries — click on them to see details including the error message, which workflow failed, and which action caused it. Server Logs also show workload unit consumption per action, helping you identify expensive operations.

> Pro tip: On free plans, Server Logs are retained for only 6 hours. Check them frequently or upgrade to a paid plan for longer retention.

**Expected result:** You can identify server-side errors, failed workflows, and high-WU operations in the logs.

### 4. Run the Issue Checker

Click the 'Issue Checker' icon in the editor toolbar (it looks like a warning triangle). The Issue Checker scans your entire app for configuration problems: missing data sources, broken dynamic expressions, elements referencing deleted fields, and invalid workflow conditions. Fix critical issues (red) first, then address warnings (yellow). Run the checker after every major change to catch problems before they affect users.

**Expected result:** The Issue Checker identifies and lists all configuration problems in your app with suggested fixes.

### 5. Create Test Users and Data for Role-Based Testing

Go to Data tab → App data → User. Create test accounts for each role: 'testuser@example.com' (regular user), 'testadmin@example.com' (admin), 'testagent@example.com' (agent/support). Set the appropriate role field on each. In Preview mode, log in as each test user and verify: regular users can only see their own data, admins can access the dashboard, agents can manage tickets, and so on. Create sample data for each Data Type to test Repeating Groups, searches, and calculations.

**Expected result:** Test accounts exist for each role, and you have verified that permissions work correctly for each user type.

### 6. Test Edge Cases and Error Handling

Test scenarios that users might encounter: submit a form with empty fields, enter invalid email formats, try to access a page without being logged in, upload a very large file, click the same button rapidly, and navigate to a URL that does not exist (404 handling). For each edge case, verify that your app shows an appropriate error message, redirects correctly, or prevents the action. Use the Debugger to trace unexpected behavior.

**Expected result:** Your app handles edge cases gracefully with proper error messages and no broken states.

## Complete code example

File: `Workflow summary`

```text
TESTING CHECKLIST

1. PREVIEW MODE TESTS
   □ Sign up flow works
   □ Login flow works
   □ All navigation links work
   □ Forms submit correctly
   □ Repeating Groups display data
   □ Conditional visibility works
   □ File uploads work
   □ Email notifications send
   □ Responsive layout at mobile widths

2. DEBUGGER CHECKS
   □ All workflow actions execute in order
   □ Dynamic expressions evaluate correctly
   □ 'Result of step X' references work
   □ Conditional actions fire/skip appropriately
   □ No unexpected null values in expressions

3. SERVER LOG REVIEW
   □ No red error entries
   □ Backend workflows complete successfully
   □ API calls return expected responses
   □ Workload unit usage is reasonable

4. ISSUE CHECKER
   □ Zero critical (red) issues
   □ All warnings reviewed and addressed
   □ No broken dynamic references

5. ROLE-BASED TESTING
   □ Regular user: can only see own data
   □ Admin: can access admin pages and all data
   □ Agent: can manage assigned items
   □ Logged-out user: redirected from protected pages

6. EDGE CASES
   □ Empty form submission → shows validation errors
   □ Invalid email format → rejected
   □ Duplicate submission → prevented
   □ Large file upload → handled or rejected gracefully
   □ 404 page → custom not-found page shown
   □ Rapid button clicks → no duplicate records created
```

## Common mistakes

- **Only testing as the app creator (admin)** — The app creator bypasses some Privacy Rules and has full access. Real users may see blank data or permission errors. Fix: Create separate test accounts for each user role and test as each one. Use 'Run as' feature if available.
- **Not testing backend workflows in the Logs** — Backend workflows do not show in the frontend Debugger. Errors in scheduled or triggered workflows are invisible unless you check Server Logs. Fix: Always check Server Logs after running backend workflows. Look for error entries and verify the expected records were created/modified.
- **Testing only the happy path** — Users will enter unexpected data, navigate in unexpected orders, and encounter network issues. Untested edge cases cause crashes in production. Fix: Create a testing checklist that includes empty inputs, invalid data, rapid clicks, and unauthorized access attempts.

## Best practices

- Test every workflow with the Step-by-step Debugger at least once before going live.
- Create test user accounts for each role and test permissions thoroughly.
- Check Server Logs for errors after any backend workflow changes.
- Run the Issue Checker after every major feature addition.
- Test on mobile devices (or narrow browser windows) for responsive layout issues.
- Create realistic test data — avoid testing with just one or two records when your app will have hundreds.
- Document known issues and their expected behavior for other team members.

## Frequently asked questions

### Can I test backend workflows without deploying to live?

Yes. Backend workflows run in the development environment during Preview. Check the Scheduler tab (under Logs) to see queued and completed backend workflows, and Server Logs for execution details.

### How do I test as a different user without logging out?

Open an incognito or private browser window for each test user. This lets you be logged in as different users simultaneously.

### Does test data in Preview affect my live app?

No. Preview uses the development database, which is separate from the live database. Data created in Preview only exists in development until you manually push data to live.

### How do I test email notifications without sending real emails?

Bubble sends emails in development mode to the app creator's email by default. Check your inbox (and spam folder) for test emails. Use the Server Logs to confirm the Send Email action executed.

### What should I do if I find a bug right before launch?

Use the Debugger to isolate the exact failing action, fix it, and re-test. For complex bugs, RapidDev can help diagnose and fix issues quickly so you do not delay your launch.

### How often should I test my app?

Test after every significant change. Before deploying to live, run through your full testing checklist. Establish a regular testing schedule for ongoing maintenance.

---

Source: https://www.rapidevelopers.com/bubble-tutorial/test-the-app-in-bubble
© RapidDev — https://www.rapidevelopers.com/bubble-tutorial/test-the-app-in-bubble