The Basics
Testing is simply trying out the different steps of your application; debugging means observing a non expected behavior and understand the root cause, before solving it. While each case is by definition different, there are a few principles that can guide you in both processes.
Using the development version
As your application has two versions, it is always recommended to test and debug on the development version of your app. Firstly, that's the version that you can modify when it comes to the app's design and workflows. Secondly, and more importantly, as soon as you are testing database-related workflows, the application's database is going to be modified. If you are not sure of your changes, it is much safer to modify the development version of your data, while live data will very likely impact real users.
However, an issue might only happen in live mode, especially when it it is reported by a user. In such case, we recommend two things:
Try to deploy the latest version of your app if it's safe to do so. If an issue is happening in live mode but not in development mode, the bug may have already been fixed in development, and you should see if deploying fixes the issue.
If an issue is hit by a particular user, it may be because of the specific data that is saved in live mode. Bubble lets you copy your database across versions. In such a case, we recommend copying from live to development. Doing so, your development version will have the same data as in live mode, which will make debugging closer to production. Then, you can run as the particular user using their reproduction steps to narrow down the issue and solve it.
Tips when looking into an issue
When you hit an issue and when your app does not have the expected behavior, the best way to tackle this issue is by having a reliable, deterministic way to reproduce the issue. This may not be possible 100% of the time, but it should be the first step when debugging your app.
Ideally, you'll want to find a succession of actions/interactions within your app that are as simple, as short as possible, while always reproducing the issue.
A good approach is also to try to reproduce the issue with a fresh set of data. For instance, a fresh user, or a fresh object (thing), etc. An issue can happen because of a legacy situation in your data, and if you cannot reproduce the issue with a fresh set of data, this is a strong hint that this is the case. The approach here is then different, instead of changing the whole workflow, a fix could be to extract the things that meet the requirements to lead to an issue, and modify these things using Bulk Operations.
Testing & debugging tools
Bubble offers two main ways to debug issues, depending on the situation. The most common is the debugger, that lets you run workflows action-by-action and inspect elements to understand where the fields' values are coming from. The second tool that is very useful to diagnose past issues is the Server Logs, that lets you analyze a posteriori what happened in your workflows. Another key tool is the Run as another user option, which is extremely helpful if a user is reporting an issue that you cannot reproduce with your own account or a test account.
Using safe modes
You can click on Preview at any time, and that will run your application on the page you are currently editing in the Editor. As changes are saved in real-time, the version you see in the Run-mode tab is always the latest version of your app (after you click the 'Preview' button). By default, the debugger will be turned on when you're running your application from this button.
Note that when you have a Run-mode tab open and you modify your app, a notification will appear as soon as the version running is older than the version in the editor. Clicking on that message will refresh the page and run the latest version in the Run-mode tab.
If you hover the Preview button for a second, you will see more preview options. You will be able to run the application without the custom HTML that you added to the page, without adding community plugins (built by the community), and without both. These modes are useful when you are debugging your app, as some custom code can sometimes conflict with Bubble's native behavior. If your issue resolves itself in a safe mode, then you know the issue is due to something introduced by a plugin or custom code.
What if you think it's a Bubble bug?
The Bubble development team spends a lot of time on testing and uses automated tests extensively to avoid bugs. However, if you think you're hitting an issue that is not caused by the way you built your app and workflows, but a non-expected behavior of a Bubble core feature, please reach out and we'll look into this. This doesn't apply to plugins that aren't built by the Bubble Team - for these issues we recommend reaching out to the plugin author.
Before you submit the report, make sure your connection is fully-functional, and that you're on the latest version of your browser.
Test the issue in Incognito mode (or 'private browsing') first, as ad blockers and browser extensions can interfere with web applications.
Remove custom code you've added to your app in HTML elements, headers, etc.
As you're filing a report, please keep a few things in mind to ensure a rapid resolution.
Try to be as specific as possible when you describe the issue. "It doesn't work, I think it is be a bug" is not specific enough. Instead, saying "based on the condition, this element should be red, but instead I see it green" is much more actionable.
Similarly to what was described above for your own debugging process, the more isolated the issue is, the faster we can look into it. In fact, it's best if you're able to reproduce the issue on a blank, test page, outside of the context of your design and core workflows.
Please make sure your instructions can be understood by someone that has no knowledge about your app. The best descriptions are 'click on button A', 'type xx in the input', 'click on button B', 'see the problem'.
Try to share screenshots, as prompted in the form.
Videos can be useful, but shouldn't replace the written from. It should only be a complement (and is usually not necessary).
We understand bugs can be frustrating and can slow down your development work. However, with the right reporting, you can help us identify issues quickly and fix them, and when the team fix an issue for you, it is fixed for the entire Community.
Last updated
Was this helpful?