When is it worth repeating a browser check with a script?
Automate a small check you need to repeat, such as confirming that a public schedule shows the correct time. Run it against a disposable local copy of your app and decide what would make the check pass.
What should your first browser check prove?
Pick something a visitor can see without signing in, such as a workshop title and time. Write the exact result you expect. A browser tool can repeat the check and record the screen. You still decide which result counts as correct.
For a local run, confirm the copy contains only fictional records, uses a fresh browser session with no signed-in accounts, and that neither the page nor its server calls outside services. Use paper if you cannot confirm those conditions.
What is the difference between a browser tool and an isolated test setup?
A browser tool repeats actions in a browser. An isolated test setup limits the files, accounts and connections available to the test. A fresh browser session can keep cookies separate, while your app could still reach the same outside services unless you disconnect them.
Start with a local copy that shows only fictional content. A test run that visits one screen gives evidence for that screen, browser and window size.
Compare tools
Scroll the table sideways to read every column.
| Tool | Which browsers can you check?The browser or engine you can actually run. | What does your project need?The language and tools used to run the check. | What can you keep after it runs?The outcome and evidence that help you understand a failure. |
|---|---|---|---|
| Playwright | Chromium, Firefox and WebKit builds. A WebKit result does not cover installed Safari. | Playwright Test for JavaScript or TypeScript. Other supported languages have their own test integrations. | Use test assertions and optional screenshots or traces. |
| Puppeteer | Chrome for Testing or Firefox, matched to the Puppeteer release. | JavaScript or TypeScript in Node.js. Choose a runner or script for your check. | Capture the page or one part of it and record the expected text separately. |
| Selenium | Chrome, Edge, Firefox or Safari where supported by your local setup. | Choose a language binding and a test runner. Check browser and driver requirements. | Wait for the expected page condition and save the browser version and screenshot. |
| Browserbase | A hosted browser for an approved rendered-page check. | Use a supported test client and an owned demo. Check concurrent session limits. | Keep permitted evidence only. Check retention and close the session when done. |
| Browserless | Hosted Chromium and supported Playwright browser endpoints. | Match your test library and plan. Use an owned demo with no real session state. | Keep the result and approved evidence. Close the session to stop browser-time usage. |
| Docker | A container packages the software you provide, including a browser if needed. | Prepare an image for a compatible host and keep the test’s files and access separate. | Keep the recipe, result and any approved output stored outside the container. |
| E2B | A hosted workspace for code. Supply a browser separately if the check needs one. | Set a time limit and use only invented input and isolated connections. | Save the chosen output and test setup before the workspace ends. |
| Daytona | A workspace where you supply your browser or other test tools. | Choose sandbox type and stop or discard settings for an isolated test. | Check which files persist and keep approved results separately. |
| Modal | A hosted workspace for your test code. Supply the browser if needed. | Choose software, CPU, memory, timeout and isolated data. | Keep the expected report and check any separate persistent storage. |
| gVisor | An isolation runtime for containers. You supply the browser or program. | Check runtime compatibility and use an owned disposable environment. | Keep the test result, container image and runtime configuration. |
What should you save when a check fails?
Save what you expected, what appeared, the browser version and the window size. Include a screenshot for a layout problem. A record of actions can help when the screen alone cannot tell you what happened before the failure.
Keep only the evidence needed to explain the result. Use fictional content so a screenshot never carries customer records or a live session.
How can you rehearse a read-only browser check?
Sketch a fictional workshop schedule. Leave accounts and forms out of the exercise.
- Draw the expected pageMark one workshop, its time and the part that should fit in a narrow window.
- Draw a result that should failLeave out the time in a second drawing. Write what the check should report even if the title still looks right.
- List what you would keepRecord the expected text, window size and screenshot you would save. The paper exercise leaves browser behavior untested.