Like other platforms, you can of course build and test out functionality and even see what it looks like to users with different user roles before publishing to your user base.
We have workflows functionality (where you can trigger emails and webhooks when data is updated in your app or when action buttons are clicked) and that would probably strike me as one of the first areas where tests could be focused as these things happen more in the background.
Defining the rules for the app could (and will) allow you to programmatically verify that it's still working as expected.
However, I think another large appeal for no-code/low-code solutions is not having to worry about testing. You can assume that because you're building your application within the rules of the platform, that everything will function as you tell it to.
If you want to verify that it works how you want vs how it's setup to work, then you would be better leaning on existing tools that can do that.
My point about not needing to test it was about the implicit trust you would put in a platform like this, just like you would trust that a library you import behaves how it describes. It's not expected that you should write unit tests and integration tests to verify the behaviour of an external library
In the case of something like Noloco, I imagine it would be more like "we need to change this DB schema, can we update the schema in a test environment and make sure that we didn't break our Noloco app?" There's nothing to unit test there but if you don't have a solid set of integration and e2e tests then you might have a form that's halfway through a flow that suddenly stops working and you don't notice until your conversions crater to zero.