App - Unit testing best practice

I’m curious how others are testing their application’s javascript queries/code. I have these “meaty” javascript queries and I’m becoming less confident in change management (ie not breaking things when changes are made). I have the same question for UI testing (eg selenium, playwright, etc) and unit testing workflow javascript blocks. Any insight would be amazing.

Hey @lkiss

Thanks for reaching out to the Retool community!

While we wait for some other developers to chime in on what they are doing, I would like to chime in that Retool provides a short guide here on writing test plans for your Retool app. Write WebDriver tests | Retool Docs

:plus: We also have this Youtube video from our page using these tools. https://www.youtube.com/watch?v=_aLPEjv-Iss

:red_question_mark: Is this what you are using now for testing? If so, are you running into any issues or just curious on a particular type of testing?

Let me know! I can do my best to help. :grinning_face:

Regards,
John | Retool Support

@John_V Thanks for chiming in.

Shhh, don’t tell anyone this – I’m not performing any automated tests with my apps. I would love to, hence the initial inquiry above.

I have a few teams here that have used Playwright without success. They ran into a number of obstacles and ditched it. I will ask around and create another topic if there were specific obstacles related to Retool specifically. I do know that to test our Retool apps requires a bunch of data in salesforce and other internal systems, and I suspect building out the “setup” data and functions to get everything into a known state before running the tests is a challenge. I do know they are going to revisit within the next 2 months.

Hey @lkiss

Happy to help out!

Feel free to just write back here whenever you hear back from that team and if any questions come up around the topic. I would be happy to help clarify further.

Looking forward to hearing back ( eventually ) :grinning_face:

Regards,
John | Jira Support

I wanted to throw an idea out, and hopefully someone can chime in on feasibility, even if they haven’t done it before.

We have protected apps within hosted/cloud retool. During some CI/CD pipeline, would it be possible to launch a container with the PR/branch in a self hosted retool environment, then somehow drop in the javascript test code “near” the retool javascript code (or maybe put in the /user directory), and then kick off a test runner (eg jest)?

A big thing will be the ability to put in mocks/spies for whatever is “below” retool resources. I have javascript query wrappers around all my resource queries. I suspect I could probably figure out how to mock the resource query so I can test the wrapper and things “above” it. But resource queries themselves should be tested since they have inputs and outpus (ie transformations) and error scenarios, etc, and I’d want to exercise all of that.

Would love some insight or even sounding board type ideas, if anyone has them.

Hey @lkiss

Would you mind posting that new question in its own post?

Then we can get some additional eyes on it from the community. Right now its still under this unit testing best practice question.

Regards,
John | Retool Support

@John_V Would you consider my reply a new post? It’s a possible solution for unit testing of code. I assume it would be better continue with the same thread given it’s the same topic. Are you saying that more people will see it if I create a new topic?

Hey @lkiss

Great question — yes, creating a new topic will give your question significantly more visibility. New topics appear on the forum's front page and in members' feeds, while replies buried in an existing thread are much less likely to be seen by others who might have ideas.

The underlying topic (unit testing) is the same, but your latest question is a distinct and more specific scenario that would benefit from its own discussion. I'd encourage you to go ahead and create that new post.

That said, I wanted to share some initial thoughts on your CI/CD + Jest idea:

On the Jest/container approach: To my knowledge, this isn't a workflow that's currently supported. Retool's JavaScript queries are stored as part of the app definition and rely on Retool-specific runtime APIs (component references, query triggers, etc.), which means they aren't standalone .js files you could import into a Jest test runner.

The /user directory in source control is designed for WebDriver test code (Cypress/Playwright) that interacts with the running Retool app through the browser — not for executing Retool JS code directly outside of the Retool environment. That said, if you do experiment with this approach and find otherwise, we'd be interested to hear about it.

On testing resource queries ( inputs, outputs, transformations, error scenarios, etc ): This is an area where our current tooling has a gap. Our WebDriver testing runs against live resources in the browser. We also have a newer native testing feature ( currently in beta ) that allows you to record interactions with your app as tests — it captures the returned data at recording time and uses that as a hard-coded mock in subsequent test runs.

However, native testing does not currently catch regressions in resource queries themselves, and it doesn't yet integrate with CI/CD pipelines. So neither tool fully addresses testing resource query behavior in isolation today.

For test data setup challenges: One approach other customers have used is configuring a dedicated testing environment with resources pointed at mock APIs or test endpoints, which can help reduce the complexity of getting external systems into a known state.

If you're interested in learning more about the native testing beta please click this URL here to sign-up.

Regards,
John | Retool Support