[darraghmckay]

That's not something we currently offer, but it's certainly something I've thought about a lot. One of the benefits of no-code tools like Noloco is that you define, very explicitly, what your app should do, display and how it behaves under certain conditions. This really does allow for completely automated integration tests. such as verifying that a filter in the UI does filter the data, verify that when User X logs in, that the permissions for that user are respected, verify that when a record meets certain conditions, a tab isn't accessible.

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.

[enos_feedler]

I am not sure I follow your logic on why a low code tool should generate apps that don't need to worry about being tested. Even regular software _should_ function the way we tell it to but the point of testing is that sometimes this changes to no longer be true _unintentially_. If I generate a low code program with your tool that should have some desired behavior, but then someone makes changes it for it to do new things, how can I be sure the old things still work and a regression has not occurred? I think there is a need to package tests along with the app, even though its being generated somewhat at a high level.

[darraghmckay]

I see what you mean, I guess the best and only way to do that would be to write integration like tests with something like Cypress, as you could with any web-app.

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

[mason55]

I wouldn't write unit tests for an external library but any integration test will implicitly test any external libraries that are in the code path. That's one of the points of integration tests - catching cases where the underlying code still works as it's supposed to but the way it's supposed to work has changed. Whether it's an external library or code you wrote, your goal is to test that all the pieces still fit together like they're supposed to.

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.

[enos_feedler]

Boom. Thank you for bringing my abstract concern into the real world.