How I vibecoded Lighthouse in a world of UI tests

Dima M — Sun, 26 Jul 2026 18:24:48 +0000

Where the idea came from

There are still .NET MAUI developers out there. They may be listed in the Red Book, but they have not gone extinct yet. I am one of them.
My name is Dima.

I work at a small company that builds a cross-platform app on top of an ERP system. That detail barely matters for this article.
At work we were looking for an automated UI testing tool that a QA engineer could use without turning into a full-time automation developer. Why now? Because of the pain of moving from Xamarin to MAUI.
The target scenario was deliberately simple: open the app, record a test by hand, and run it on the server with every release.

Our product is on .NET MAUI, so “every release” is not one environment — it is three: desktop, Android, and iOS. With a shared UI you would like to run the same test on different platforms. You can also record the same tests three times; that is not the most critical part.

The first candidates were the usual enterprise products — Ranorex, TestComplete, and the like. They are powerful systems, but hard to learn (Android there is a special kind of horror), expensive to license, and often a poor fit for a QA who is strong at finding defects but does not want — and should not have — to dig through the tool’s structure and visual tree just to add a control for verification. We wanted something closer to record-and-run, with a clear story for cross-platform control identity.

After a few evaluations it was clear that the combination “simple for QA + cross-platform + stable ids” is almost nowhere on the shelf.
That is when I asked myself: how hard is it to build what I am looking for? That is when the vibecoder in me woke up.

I tried to do it in the evenings, outside work hours. The result is Lighthouse Tests Suite, early beta: lighthousetests.com. All in all I spent about six days, two to four hours at a time — whenever I could.

Vibecoding without rose-colored glasses

I built this in Cursor, model Grok 4.5 (auto-select in newer versions). The model is genuinely fairly “smart” and quick. It thinks faster than the previous ones. Periodically you still have to poke it with a stick so it does not get lazy; sometimes it suggests options that are simply not a fit — but that is rare. Overall I am more satisfied than not.

If someone thinks AI will take over the world — you can relax for a bit; there is still some time. So the scheme is simple: I decide what we build and where we cannot afford to be wrong; the model prints kilometers of glue. A classic junior on steroids, only without coffee and perks.

In a weekend you can knock out “I attached to Calculator, recorded a click, here is a screenshot in Telegram.”
But to have:

recording and playback on Windows;
at least some Android path via Appium;
a site, an installer, CLI/API to “run on the server”;
a UI where QA does not cry at an empty screen —

that is no longer a weekend. Ask me how I know.

Below is not a full repo tour — just the places where vibecoding without engineering hits a wall fast.

What came out

Lighthouse is a Windows desktop app (.NET 10, WPF). The idea is simple:

Attach to a Windows process (FlaUI / UIA3) or to Android (Appium UiAutomator2).
See a UI map — screenshot plus element overlays.
Record steps (or right-click the map: assert / wait, and so on).
Run again. Check the dashboard.

The bet is AutomationId. In MAUI that is a normal story: put an id on a button, and you have a chance to run the same intent on Windows and Android without rewriting everything from scratch. Flutter with Semantics(identifier: …) is the same song. iOS is not there yet. I wrote myself the credo “write once, play everywhere” before I had dragged the third platform across the finish line. It happens.

One small thing that annoyed me: the menu showed a pretty name like Display is 1, while playback went by #CalculatorResults. It looks as if the test is lying. The preview now shows the id as well — more honest that way. Playback was already finding by AutomationId; the lie was only in the UI.

Guide and docs: guide, docs.

Stack and solution layout

Roughly:

Lighthouse.Tests.Suite.slnx
├── Domain          — steps, suite, UiElementNode (snapshots)
├── Application     — interfaces, script, portability helpers
├── Infrastructure  — FlaUI, Appium, UiAutomationWorker, persistence
├── App             — WPF + ViewModels (MVVM, CommunityToolkit)
├── Cli / Api       — headless runs
└── website/        — product site (Cloudflare Pages)

Stack: .NET 10, WPF, FlaUI (UIA3), Appium for Android, Velopack for Setup, NLog, local HTTP API on loopback.

Why layers: Domain does not reference FlaUI/WPF. Only immutable UiElementNode / overlays live on the UI thread. All COM/UIA runs on a dedicated worker. A month later that saves you from wanting to burn the repo down.

The user Workspace is three columns: test list · steps/script/Run · Inspector (map + Start Recording). Script in the center is Monaco. For releases there is also a CLI and POST /v1/runs (one active run, SSE for progress) — so “run on the server” is not only a WPF button.

Windows UIA: threading, snapshots, locators

Worker + message pump

You cannot casually call FlaUI/COM from the WPF UI thread “however it goes.” In Lighthouse all access goes through UiAutomationWorker (STA + message pump): Invoke / InvokeAsync. From the worker you must not synchronously call back into Dispatcher.Invoke — classic deadlock path. Long tree walks call PumpMessages() periodically, or UI Automation and the app start to choke.

Product rule: never expose a live AutomationElement. ViewModels and the canvas get snapshots. Otherwise within a week you have a race: the tree is already dead, and WPF is still painting a “live” element.

Locator priority

On playback the condition is built roughly like this (simplified):

AutomationId present → ByAutomationId;
else Name + ControlType;
else Name;
else ClassName / ControlType.

Same rule for the Windows path and for scoring selector “quality” in the inspector. Name is fine for humans or a Calculator demo; for release suites without ids, building repeatable tests gets painful fast.

Recording: why not `TreeScope.Subtree`

The “logical” suggestion from a model or a textbook: on record start, hang text-change handlers on the whole tree (TreeScope.Subtree). On a live UI that easily turns into multi-second freezes.

Recording ended up closer to a practical minimum: hit-test on click / map + text capture around focus-leave, without heavy subtree listeners for the whole attach. Less magic — fewer freezes.

Android and AutomationId portability

Android path: Appium + UiAutomator2, screenshot on the canvas, recording from the map (plus optional live taps via adb getevent and polling the focused EditText for EnterText when the session is alive).

Main portability contract: if a step has an AutomationId, Android locates by id only, with no Windows class/bounds fallthrough. Otherwise “move the test” becomes a geometry lottery.

In the app under test it looks familiar:

// MAUI
Button.AutomationId = "login_button";

// Flutter
Semantics(identifier: 'login_button', child: ...)

The tool has a portability check on import and a separate id probe on the connected device. Steps without an id and platform-only kinds (screenshot assert, Windows drag, Android Back/Swipe) are honestly marked as “will not migrate by themselves.”

No iOS in beta. I wrote the credo; iOS is still only in the plans. The problem is not really implementation — it is that I have nothing to verify it on (for now).

Everything around the inspector

Without this, “run on every release” stays a slide:

Piece	Why
JSON persistence	suite under `%LocalAppData%`, autosave
CLI	`run` against exe / Android package, report
Local API	loopback, `POST /v1/runs`, SSE progress
Velopack	Setup + update feed (public URL, not private GitHub Releases)
Website	guide, FAQ, changelog, download

The inspector is the heart — most of the work goes through it. The rest is polish and attempts to make life easier for the user. That is how you quietly end up with six evenings instead of one Saturday night and “hello, Calculator.”

What I took away (not prescribing it to you)

About Ranorex / TestComplete: they do their job, and our goals were different. Ours was to give QA a “record — run on release” button, not a second career of “living inside the combine harvester.” Sometimes an expensive combine is the right answer. Sometimes it is an elephant you send to fetch a bag from the shop.

Next, ids. You can talk about “write once, play everywhere” all you like, but if the buttons have no AutomationId, you do not have cross-platform — you have two (or three) separate sets of fragile selectors under one pretty slide. After Xamarin, on MAUI that hurts especially: the UI is shared, and the tests somehow drift apart again. Ids are boring. Ids are also what the shared-test fairy tale dies without — usually on the second emulator.

About vibecoding. Yes, the model ships fast. No, it does not remove your responsibility for a choice that is “logical on paper.” TreeScope.Subtree on record start is a good example: sounds right; on a live tree it is heavy. AI already almost rules the world in slide decks; in code it still sometimes suggests something elegant but expensive in latency. Review was not cancelled. Not even in the evening. Especially in the evening.

And last — a small thing from the “it costs time now, it costs more later” series. While Lighthouse lived only as a folder on disk, it was a pet project. When a site with a guide and a real URL appeared, it started to look like a product you can send a colleague without a half-hour explanation.

How product look now:

Plans for the future

This is beta, so the roadmap is honest — not “everything at once,” but where I am looking next.

Platforms. The main gap versus the credo is iOS. Same idea: AutomationId / semantics identifier as logical identity, a separate backend next to Windows UIA and Android Appium. Until iOS ships, “everywhere” in the slogan is ahead of the fact.

Android. Today that is inspect + map + basic playback and pieces of live recording. I want it denser: more stable gesture/text capture, fewer surprises after on-device navigation, less manual Appium hassle for someone who only came to “record a smoke.”

Assertions and selectors. assert visible on an element with an id is fine for “the screen is there.” For calculators and forms you often need the next step: assert by value / text (do not confuse Name in the preview with the locator). Also keep sharpening UX so the step preview always matches how playback actually finds the control.

Release and trust. Code-sign the Setup (SmartScreen is a typical unsigned-beta story). A calm public update feed. Post-beta: real payment / activation (Lemon Squeezy infra was already sketched; UI is not there yet) alongside the trial and offline LH1 keys.

Headless / CI. CLI and local API already exist; next is less friction for “drop in a suite → runs on the pipeline,” reports, and QA/dev wiring without mandatory clicking in WPF.

Product for QA. Fewer empty states, clearer playback errors (“did not find #id” vs “found the wrong thing”), import/portability without a quest.

Separately — a friendly test editor: not only Monaco/script and the step list “as recorded,” but a form where QA can edit click / text / assert / wait without feeling stuffed into a developer IDE. Same goal as at the start: record — tweak — run on release, without a second career inside the combine.

I am deliberately not carving dates in stone. Evenings are finite; the priority is not to break what already works on Windows and Android.

Closing

I started this not because I wanted another side project for the portfolio, but because nothing on the shelf matched what we wanted for QA after Xamarin → MAUI. In the evenings Lighthouse appeared: beta, no iOS — but with a real attach → record → run path on Windows and Android, a clear AutomationId contract, and a headless path for the server.

If the models take over the planet tomorrow — at least their tests will have AutomationIds. Until then: lighthousetests.com, and please — ids on the buttons.

P.S. If you do not feel a sudden urge to kick the author, I would welcome constructive criticism in the comments.

DEV Community: Dima M