Test values for Server Connect Library Actions

Would it be possible to persist test data in the API action (Define API Schema) section? I find myself having to enter multiple fields every time I make a change in the API Action UI. It is time-consuming and frustrating.
Custom DB queries, for example, have test data that is saved and available each time you open the window, could the API action do something similar?

An alternative, that could be hugely powerful in my opinion, would be a SC formatter such as .test() that acts like kind of like default but is only parsed in the Wappler UI to fill values when fetching schema or for database connections etc… You could then have a section in Globals for ‘test values’ that it could pick from.

Just one example and a big use case for me is dynamic database connections. I have multi-tenancy built in to my platform where each client has their own DB and the connection is made based on their login. When working with the connection, I currently have to have a ‘test’ connection as well as the dynamic one. When adjusting queries, I have to use the test one that has fixed values before switching every single query to the dynamic one before publishing. If I miss one out by mistake (which is easy in some complex API files), it can be hugely problematic. Once set to the dynamic connection, the schema is not fetched for that connection and therefore not available in either server-side or client-side data pickers.

If, for example, the DB host could be set to {{somedynamicaddress.test($_test.dbhost)}}
or more simply {{somedynamicaddress.test('hostaddress')}} (entered as a string)
it would mean I could use the one DB connection. The same principal could be used in the API Action Input Data/Headers/Query to send test data for fetching schema.

Yeah. It would be great to have something to help with this, although I can’t start to imagine how it would be implemented.

SC is so diverse and any data and field is subject to be tested.

But if they come up with something it would be awesome as I also spend a lot of time testing them and changing values for this.

1 Like

That’s why I though a SC formatter might work - making it UI only though…

The problem with the formatter is that it would be migrated as code to production. It could be dangerous to have in production “testing data and logic”. Something could go wrong.

I would feel more comfortable if it was an inyected value that lives only in the UI like with the query builder as you mentioned.

For me the main problem is using testing data coming from the input parameters. I wan’t to set a query that uses data from $_GET.field but I can’t set a test value for it unless I use postman or similar.

What about giving a real use to “Open in browser”

image

Change the name to “test in browser” and figure a way to add in the UI test values for all parameters that could be subject of testing and then run the API checking if a test value was added in the UI.

That’s useful for testing the Library action as a whole but doesn’t help with retrieving schema, for example, in specific action steps and making it available to a picker.

I don’t know enough about the foundation of SC, maybe the collective genius of the Wappler team can come up with something…

1 Like