Introduction to testing and debugging
This section covers general advice for testing and debugging your app
First, let's spend some time to define the different terms included as you prepare your app for live users:
Testing is the process of trying out the different steps of your application to check that it works as expected. It doesn't have to mean something wrong, but if there is, testing is meant to uncover it.
Debugging is done when you've observed a non-expected behavior. It's the process of understanding the root cause of the issue so that you can rectify it.
This introductory guide will give you some general advice on how to test and debug your app, before we move on to the tools that Bubble offers.
Every Bubble app consists of two environments: Development and Live. Development is a fully functioning version of your app that you (and your team) can work in together to see exactly what the finished app will look live. Live is the app that your users see.
The two environments have database that operate completely independently of each other. In other words, in the Development environments you can make changes to your database that have no effect on your live app, making it a completely safe environment to experiment in whichever way you need to.
You should always aim to fully complete testing and debugging before deploying your app to Live.
Testing is all about using your app as your users would, and working systematically through all pages and features to identify issues. While this guide will not outline what a systematic approach should look like (everyone works differently), we will still encourage you to be mindful of how you organize your testing.
If you are testing something and see an issue elsewhere, take a note for later and stay focused on the task at hand. Letting your focus drift from place to place is an easy way to miss things, so remember to stick to the plan, but note down anything else you see.
An app with no data in it and an app with lots of data can behave very differently. Adding test data can help you identify issues related to design, performance and security.
If your app is going to be used on different screens and devices, it's a good practice to test it on different resolutions and maybe even throttling the connection speed and CPU. Chrome Developer tools offers a highly useful Device Mode that lets you do all of these things.
As you introduce privacy rules and conditions, your users will start to experience the app differently. Some users may have access to specific parts of your database and app, while others don't. In these cases it's useful to make a habit of testing your app as different users.
For example, if you have two user types, user and admin, it's likely that one has a different access level than the other, and you may miss issues or inconsistencies if you only test as one of them.
To use your app as a specific user, simply search for that user in the built-in database editor and click Run as.
Using the Run as feature lets you easily test your app as another user without having to know their credentials.
As you keep testing your app, you will uncover the occasional issue – don't worry, it happens even to the most experienced developers!
When beginning to debug an issue, the key initial step is to establish a consistent and predictable method for reproducing it. In practice, this involves retracing your steps and running multiple tests to confirm that the issue consistently appears every time, and with the same characteristics.
This lets you get a firm grasp of the problem before you spend time tackling it.
Each issue you find may have more than one cause. As you identify it or them, stay focused on one at a time. It can be useful to find ways to test that the cause you're currently working on is fixed before moving on to the next. Again, keep notes to make sure you don't miss anything.
Many issues are related to data being unavailable because of privacy rules. Keep in mind that they apply everywhere (elements, workflows and conditions), so it's often a good idea to check the rules for the relevant data type.
If the error has been reported by one of your users, you should try to collect as much information as you can about the circumstances that produced the error.
- Which user is it?
- What kind of device and browser are they using?
- Are they using ad blockers or script blockers of any kind?
- What were the exact steps they took to produce the issue?
- Can it be reliably reproduced, or could it be because of a poor connection or other external reason?
Bubble has an incredibly welcoming and helpful community. If you ever find yourself stuck on an issue, don't hesitate to seek help! Share your problem on the Bubble forum, reach out to our Success Team, or hire one of our expert coaches to assist you in resolving it.
Sometime issues are best solved on a walk outside, in the shower or lying on the couch. Other times you simply need some time to refresh your mind before returning to the screen and continuing the search.
Your brain is a muscle – it too needs rest between the sessions!
Bubble offers two ways to debug issues, each serving a specific purpose:
The debugger is a small panel at the bottom of the screen when you are running your app in Development. Using the debugger, you can:
- Run workflows action-by-action and check data (such as the result of a search) related to each step
- Inspect the elements on the page to check their attributes, conditions and associated data
The second tool for diagnosing past issues is the Server Logs. This feature allows you to retrospectively examine what occurred in your workflows and check any unexpected behavior or errors.
Our Academy quick tip on how to preview your app in safe mode
Safe modes is a way to preview your app, but disabling certain parts for debugging purposes:
- HTML - this disables on-page HTML elements
- Community plugins - this disables community-made plugins
If the issue resolves itself in Safe mode, you'll know it is due to something introduced by a plugin or custom code.
You enable Safe mode by holding the mouse button on the Preview button for one second. A dropdown will show you the list of options.
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.
Reporting bugs to the Bubble team should always be done via the Bug Reporting tool, that prompts you to fill out the different necessary information for the team to look into it. Before you file a bug, please do a few things to ensure this is a real bug.
- 1.Before you submit the report, make sure your connection is fully-functional, and that you're on the latest version of your browser.
- 2.Test the issue in Incognito mode (or 'private browsing') first, as ad blockers and browser extensions can interfere with web applications.
- 3.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.
- 1.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.
- 2.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.
- 3.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'.
- 4.Try to share screenshots, as prompted in the form.
- 5.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 modified 1mo ago