Blop AI
Blop turns design feedback into code you can ship
Start new thread

Blop - Describe your app and Blop tests it and repairs broken tests

by•
Most startups ship fast and have no QA team, so tests get written late, break often, and quietly get ignored. Blop fixes that. You describe what your app should do in plain English. Blop builds a deep map of your product, tests it like a real user on every deploy, and when something changes and a test breaks, it repairs the test and opens a PR for you to review. The tests stay as real code in your repo. You own them. Nothing locked inside our tool.

Add a comment

Replies

Best
Maker
📌
Hey everyone, Alejandro here, one of the cofounders. Me and Hanan build a lot with vibecoding tools, and we kept hitting the same wall. You move so fast that you stop reading every diff, and slowly a gap opens between you and your own codebase. Clean code you don't fully understand. It shows up worst when something breaks and you can't tell if the test is wrong or the app is wrong. We wanted something that understood our projects as deeply as we used to, back when we read every line. So we built Blop. It holds the full picture of what your app is supposed to do, watches it on every deploy, and tells you when reality drifts from intent. It repairs its own tests and hands you a PR, and everything lives in your repo as code you own. We're opening it up to startups and SaaS teams now. We mostly want honest feedback, especially the critical kind. What's confusing, what's missing, what would make you actually use it. Happy to answer anything here.

How does Blop distinguish between an intentional product change and a bug ? I'd be curious to understand what signals it uses before deciding to repair a test automatically.

Maker

 The real answer is we don't let the runtime make that call at all, because it's the wrong place to make it. The runtime only ever recovers a locator, finding an element that moved. It never changes what a test expects. So a refactor that renames a button gets recovered quietly. A broken checkout flow fails loudly, because the expected outcome didn't happen and we never touch assertions. The "is this a real change or a bug" decision happens one level up, and a human is always in it. When something drifts, Blop opens a PR with the proposed update, the trace, and a diff, and you decide. We deliberately don't auto-merge anything. The signal we lean on is simple: did what you described still happen? If yes, it's structure that moved and we adapt the path. If no, that's a failure and it's yours to look at

Congrats! I wonder how does Blop ensure the generated test code matches your team's existing patterns and naming conventions?

Maker

 Thank you! That’s actually something we’ve been working on quite a bit.

We added a knowledge base where teams can define their test patterns, naming conventions, helpers, and preferred structure. The agent also updates its memory as you use it, so it can learn from feedback and generated tests over time. The goal is for Blop’s tests to feel like they were written by the team, not dropped in by an external tool. We’re still looking at how we can improve this further.

Ok two feedback’s 1. Your idea is solid and it’s true I have myself shipped vibecoded ios apps that have paying customers the issue is testing and figuring out what is broken. 2. Demo video is really bad after opening for 2-3 sec I stopped cause it didn’t grabbed the attention it is simple I mean the zoom in and zoom out thing is cool but you should do something random in 1-4 sec of the video.

If it auto-fixes its own tests when the product changes, what stops it from "fixing" a test into passing when the underlying behavior actually broke? That's the core tension with self-healing test tools generally, how do you tell the difference between an intentional UI change and a regression if the system's first instinct is to adapt rather than flag?

Maker

  Good question, this is the thing we worried about most too. The trick is we never let it touch the part that matters. Blop keeps two things separate: how a test finds stuff on the page (the locators) and what the test expects to be true (the assertions). Self-healing only ever touches the first one. If a button moved or got renamed, it can re-find it. But if the thing you said should happen didn't happen, that's a failure, full stop. It never adapts an assertion to turn a red test green.

So an intentional UI change usually looks like a locator drifting, the button is still there, just in a new spot. A regression looks like the expected result not showing up. We only auto-recover the first kind, and even then any real fix lands as a PR you review and merge yourself. Nothing rewrites your test behind your back. You get the trace and the diff and you make the call.

The self-healing part is what I keep thinking about. Writing tests is one problem, but the real grind is maintaining them after every refactor, and that's usually what causes teams to just give up on the test suite entirely. The "deep map" approach of tracking intended behavior rather than implementation details sounds like it could survive code changes better than traditional tests. The concern I'd have is the edge case where Blop quietly repairs a test that was actually catching a real bug. How do you distinguish between a test that broke because the product changed versus a test that broke because something is genuinely wrong?

Maker

 That’s a great point, and honestly it’s something we noticed too. Self healing can’t just mean “make the test pass again” because then you risk hiding real failures. There’s also the agent reward hacking problem if the goal is just green tests, agents can create shallow tests that don’t really validate the feature.So for us, the key is that repairs should be anchored to expected behavior and remain reviewable. Blop should explain what changed and whether it looks like an intentional product change or a real regression not silently auto fix everything so the goal is assisted maintenance with guardrails, not blind auto fixing :)

The timing for this feels right. Vibe coding makes it easy to move fast, but after a few rounds you start needing something that remembers what the app was supposed to do.

Maker

 Thanks! Exactly vibe coding helps you move fast, but once you have a lot of products, the knowledge gap around what each app is supposed to do becomes real. That’s what we’re trying to solve with Blop.

Do you plan support for mobile/multi platform/cli products testing as well?

Maker

 Hi! We’re currently working on mobile testing in the web app, as well as a Blop CLI that already powers our backend testing infrastructure. Soon, you’ll be able to use Blop directly from the CLI for your own workflows.

We also have an npm package available already . We’re actively working on improving and publishing the documentation for it, so it’ll be much easier to get started soon.

the vibecoding gap you described is painfully accurate, you move so fast you slowly stop recognizing your own codebase. the thing that makes me trust this is that the tests land in my repo as real code i own, so when it opens a PR i can read exactly what changed. nice work Alejandro.

The locator-only healing is a clever constraint - it answers the regression-masking concern pretty cleanly. The harder problem I'd push on is spec drift: "user can sign up and check out" sounds stable but the flow itself evolves constantly in early-stage products. When checkout adds a promo code step, or signup adds phone verification, Blop's deep map of expected behavior is now wrong - but locators might still pass. Does Blop have a way to surface when the original description no longer matches what the product actually does, or does that gap just quietly accumulate until a real regression gets missed?