UI testing tools explained for people who build and ship sites

UI testing tools are frameworks that open your app or site, click and type like a user, and read what is shown, so a whole flow can be checked without a person. They are not part of FlowLatch. You pick and install one, and FlowLatch runs it through Shell, reads the output and edits the test files that the framework reads.

A flaky test passes and fails with no change in the code, and nobody trusts a red result after a few of them. The usual causes are fixed waits instead of waiting for a visible condition, selectors tied to page layout, shared test data and tests that rely on each other's order. Handling network failures in e2e tests also means waiting for a condition, not adding a longer pause.

A unit test checks one small piece of code, an integration test checks parts working together, and an end-to-end test walks through a whole flow in a real browser against a test copy of your app. End-to-end tests are slower and more fragile, so keep them for the few flows that must never break. In a release process, e2e testing runs after the fast tests pass.

None of its own. GUI testing tools are the frameworks that drive a browser or the interface of a desktop program, and you choose one. FlowLatch has no browser driver and cannot watch the screen live. It runs the framework you installed through Shell, shows the real exit code and edits the test files, while the framework does the clicking.

Only sites and apps you build, own or are authorised to test, using test accounts and fake data. Email checks go to a test inbox that you set up for the test. For payment flows use the test mode of your own payment set-up, never a real card. FlowLatch is meant for your own systems, and you keep the work within them.

FlowLatch is an agent that runs tools in your working folder and shows each action as a card with its real result. It finds tests with list_dir, glob and grep, reads them with read_file, changes them with write_file and edit_file, runs your test command through Shell and reads a saved failure screenshot with ocr. Every change reaches you as a diff first.

Yes, testflowy.com is the official FlowLatch website. Download the setup program of about 34 MB from the download page and compare its SHA-256 checksum with the published manifest. FlowLatch is independent and not affiliated with any testing framework, browser maker or testing service. If something looks wrong in the app, the Send feedback button inside it reaches us, and the checksum tells you whether the file is the original build.

No. FlowLatch runs the real command and shows the real exit code, but a model can misread a failure or write a wrong edit. Read every diff and run the tests yourself. A green run lowers the risk of breaking a flow, and it does not prove the app is free of bugs. Tests also need regular maintenance, so schedule time for it.

Ask first is the mode to start with. It pauses before actions that change something and shows the diff you accept or reject. Auto-run acts at once and suits steps you have already reviewed, and Plan only writes a plan and runs nothing. You can switch modes at any moment, for example to Plan only for a first look at a new project.

Yes. Cron runs a prompt on a schedule, so you can ask FlowLatch to run your test command at the times you set and report the exit code in the chat, for example every morning before work starts. Plans survive restarts. Choose the approval mode with care, because Auto-run acts at once and Ask first waits for your OK before an action that changes something.

The answer depends on the model you pick. With a cloud model, your prompt, including the text of files the agent reads, goes to that provider. With a local model nothing leaves the machine. Chats, working folders and API keys stay on the PC, and secrets in tool output are redacted before they reach the model. Choose the model for each project with that in mind.

A cloud AI provider through a standard API endpoint, a model running locally on your PC, or the built-in model, which is ready to use without your own endpoint. The Test button checks an endpoint and shows the response time and the context window. A bigger model suits refactors, a smaller one suits small edits, and run_on_model sends one hard step to a bigger model.

A checksum comparison is the check: run certutil -hashfile on the file in a Windows terminal, with SHA256 as the last word, and compare the result with the SHA-256 value in the published manifest. The installer is not code-signed yet, so SmartScreen may warn. Choose More info, then Run anyway, only after the two values match, and not before.

This website is made of static pages. Hosting and a CDN process IP addresses and access logs, and a visit counter from statinside.com records page visits. Pressing the download button records the time, IP address, browser user agent and referral source, if any, to count downloads, and then redirects you to the installer. The privacy page describes the app as well as the website.