Part of it is how you structure your app and how your teams are aligned to new releases. Traditional ‘unit testing’ is approached differently in bubble, and it would be more like integration tests and front-end tests combined with Bubble’s built in ‘alert’ system that finds ‘things’ and ‘page objects’ that break as you modify your app.
An example: Try to build all of your functions as workflows. Then you can use Preflight, or Selenium, or even custom workflows to do basic integration testing by building ‘testing pages’ that only test those individual functions. Then also use Sel/PF for full end-to-end tests on your public pages.
I use Selenium on one of my production apps for smoke tests and am looking at Preflight for another.
As far as branching and merging and other traditional approaches, that completely changes with Bubble. For example, if you want to work in small increments, the entire team works on that release, much like a ‘mainline development’ strategy. Having multiple teams work on multiple versions and then merging them in bubble will be just as messy as traditional development methinks.