Launched this week
Blendra
Record a flow once and get a Playwright test project you own
46 followers
Record a flow once and get a Playwright test project you own
46 followers
Record a flow in desktop Chrome and get end-to-end tests as a Playwright project: specs, page objects, locator files, test data and a GitHub Actions workflow. After each step, tick what your app showed (a message, a URL, a heading). Each tick is a check with the real value. No LLM writes the code: same recording, same output. It runs in your CI without Blendra. On Blendra's cloud runner, a failed test gets a rule-based cause with evidence. Free plan. 7-day Pro trial, no card.
Free Options
Launch Team
ClarifyThe autonomous CRM that helps you sell more
Promoted
Hi, I'm Blend, a solo developer from North Macedonia.
For about 3 years in QA automation and frontend, I kept rewriting the same end-to-end tests whenever the UI changed. I built Blendra for developers and QA engineers who want tests they'd keep in the repo.
Record a flow once in desktop Chrome and get:
No LLM writes the code: same recording, same output. It runs in your CI without Blendra. Nothing is sent without an API token, and with BLENDRA_REPORTER=off it never contacts Blendra.
No account: paste a Playwright codegen script into the free converter (or press Try a sample) and get page objects in your browser tab. Nothing is uploaded.
https://blendra.app/tools/playwright-codegen-to-page-objects
No extension: sign up free and open the sample project, a recorded checkout with its checks and Playwright test.
The first 10 paying customers get 30% off for as long as they stay subscribed (applied automatically, offer ends 31 Dec).
I read and answer every comment, harsh ones included. When your UI changes, what breaks first in your suite: locators, test data or the flow itself?
congrats on the launch blend. to your question, i think the flow breaks first more than locators. one new step in onboarding and the whole recorded path is wrong -> locators you can fix in one file like you said. can i re record only one step instead of the full flow?
Thanks @agshin_rajabov , and I agree: a locator is a one-file fix, a changed flow is the expensive one.
You don't have to record the whole flow again. Record only the new step. Blendra adds it to the project's page library with its locator. Then open the test builder, build the flow from the steps it already has, and put the new step where it belongs. No full re-record.
If you'd rather record the flow again, "Import a new version" replaces the steps and keeps your scenarios and checks.
The 'no LLM writes the code, same recording = same output' line is what sold me — I've been burned by flaky AI-generated tests that change every run. For me it's usually the locators that break first when a button moves, so having each locator live once in a file I can edit like normal code is the part I'd actually use. Going to try the free converter on one of my own flows and see how clean the page objects come out.
@jcbuilds Thanks, JC. That is why no LLM writes the code: same recording, same output.
For the converter, paste a script from npx playwright codegen. Each page class keeps its locators together at the top, as codegen wrote them, and the ones that depend on position or a generated id get a Review comment.
In the full product each page gets its own locators file. Edit it by hand and npx blendra pull skips that file, or use "Repair locator" on the failed test: you pick another locator recorded for that step and approve it.
You can try that on your own app with the 7-day Pro trial, no credit card required: https://blendra.app/signup?trial=pro
Tell me where the page objects come out less clean than you want.
no LLM writing the code and same recording = same output is the reason i'd try it, flaky generated tests are worse than no tests at all
on your question abuot what breaks first, my guess is locators most of the time. when a button moves into a new component, can you fix the locator file once and every spec picks it up??? or is it a re-record of the flow???
Thanks @thamibenjelloun , that's exactly why I kept the LLM out of the export.
On your question: no re-record. Each locator lives once in a locator file, the page objects read from it, and the specs only call the page objects. So when a button moves into a new component you fix that one locator and every spec that uses it picks it up.
You can do it two ways: edit the locator file in your repo like any other code, or repair it in Blendra, where you pick one of the alternative locators that were recorded with the step and approve it, then download the project again. A re-record is only needed when the flow itself changes, like a new step in the checkout.
Locators are my guess for #1 too. What do you use today when one breaks?
Generating a complete Playwright project from recorded flows is really useful. When the UI changes, can Blendra update existing assertions and page objects without requiring developers to rebuild the test?
Thanks @mahmoud_shawkat . Mostly yes, and you approve each fix. Nothing is rewritten while your tests run.
- A button or field moved or was renamed: the failed test offers "Repair locator". You pick one of the other locators Blendra recorded for that step, see how many tests change, and approve. There is Undo.
- A text changed: a failed run on Blendra's cloud runner shows what the check (assertion) expected and what it saw. If the same element now shows a new text, you accept it or mark it as a bug. Otherwise, and after CI runs, you edit the check in Blendra.
- The flow changed, or no recorded locator fits: record it again and import it as a new version. The test keeps its checks.
The fix reaches your repo with the next download or npx blendra pull (Pro and up). Pull skips files you edited.
How repair works: https://docs.blendra.app/manage-locators#repair-a-locator-from-a-failed-run