Show HN: Donobu – Mac App for Web Automation and Testing (donobu.com)
You can optionally use AI (BYOK: bring your own keys) to create flows for you and to do other interesting things, like making vision-based semantic assertions. Also, your data lives on your own filesystem, and we do not see any of it (further still, there is no phoning home at all). A nice benefit of this being a desktop app rather than a SAAS product, is that if you happen to be developing/iterating on a webpage locally, this has no problem hooking into it.
What this intends to be a good fit for: - Testing web pages, especially locally. - Exploring random webpages with a stated objective. - Automating tedious flows. Rerunning a flow won't get caught up on using a single selector (many websites randomize element IDs, for instance), there is smart failover using a prioritized list of selectors. - Getting a quick draft of an end-to-end test in Javascript.
What this is a bad fit for: - Mass web scraping (too slow). - Adversarial websites.
What we are still working out: - Click-and-drag operations. - Websites that are primarily controlled from canvas. - Smoothing out UI/UX (we are two backend engineers trying our best, and are handedly outgunned by real frontend engineers).
Fun things to try: - Asking it to assert that a webpage has a certain theme. - Asking it to run an accessibility report for a page (uses https://github.com/dequelabs/axe-core). - Asking it to run a cookie report for a page.
The tech: - Java 21 for the main business logic. - Javalin 6 for the web framework (https://javalin.io/). - Playwright for controlling the browser (https://playwright.dev/java/). - Axe for running accessibility reports (https://github.com/dequelabs/axe-core).
Critical feedback is welcome. Thanks for trying it out!
Cheers, -Justin and Vaz
36 comments
[ 0.34 ms ] story [ 141 ms ] threadIt's like the old Apple commercial: "There is no step three."
Congratulations on the launch!
My question was really about the page interactions and the assertions being driven by AI: if they are going to be generating different code every time the test runs, how can you have any confidence in the test not having false positives and false negatives at least some of the time, unless you read the generated script each time?
That sounds like a lot more work than just writing the test once in the traditional way (codegen or manually) and tweaking it only when there's a breaking change to the page.
If people are genuinely using this approach then there must be something I'm missing.
Regarding variability of flows, you can cement a given flow by pressing the `rerun` button. That takes AI out of the driver's seat and the flow will rerun the set of actions decided on in the original flow as if it's on rails.
Regarding creating a test manually, that will be a best fit for pages that have consistent selector logic for elements, though we found that as soon as a page starts randomizing element IDs, this approach starts to struggle. We get around this by creating a prioritized list of selectors for every action that touches the DOM, so that if `document.querySelector("#shenanigansId")` fails, the run can still continue by choosing the next-best selector, and so on. Thankfully this logic requires no AI at all, though it is heuristic at the end of the day.
The Playwright dev team would probably say that you should avoid using IDs as selectors and instead favour the use of selectors based on user-visible aspects, e.g. "a link including the text 'cat'" or "a button with the label 'register now'". That way your tests are immune to under-the-hood changes the user is oblivious to. The range of selector options (locators in their world) are a real strength of Playwright.
I just downloaded the application, but are unable add OpenAI API keys. Looks like it's probably on my end (with quite an aggressive DNS blocking lists). So my guess here is: I'm unable to add API keys when telemetry is blocked.
Suggestion: please do add some error message when then this occurs. As in, did the request fail (500), faulty key etc
Regarding debugging your specific problem, when an API is attempted to be added, the local process attempts a 1-token request to the cheapest model with the GPT platform (in your case, gpt-4o-mini on OpenAI) to verify that the key works. Though, if the account has no balance, this request may fail even though it costs a fraction of a fraction of a penny (though anything that fails that request will cause the API key to be considered invalid).
I noticed in your video that Donobu does not move the mouse to the search box before typing in it. I hope this does not trigger captchas or anti-bot protection--I was thinking of adding "Firebase App check" to my website since Firebase recommends it to everyone and it uses "Recaptcha Enterprise". not sure if this will turn my website into an "adverserial website".
I think Donobu would also be a lot more helpful on mobile since there are more phones than desktops in general. I was looking for some kind of automated mobile testing and found none. quickest way I can think of to add that is using the new iOS 18 with desktop control of the phone.
I think you could "easily" translate this to arbitrary desktop control test software. or make some other agent software that does. if you don't someone else will https://youtube.com/clip/UgkxcFMelp1K31l7pH0Sbghb4sJ-eF0O8-x... If you made the desktop control software, I think you would get mobile control software for free.
Regarding exporting to Javascript, seems you found the button for it. Though we like to call it a "draft of a script", as it is generated by an eager-to-please LLM, so having a real engineer give it a look over is useful. It should be enough to get you off the ground though.
https://www.dropbox.com/scl/fi/8npc2rppe0soyz15dmbhk/screens...
Edit; it's actually really impressive; I try them all every so many months but this one seems to be the first one that actually works.
Any near term plans for exploring the use of local LLMs?
e: and the magic link doesnt work: Sorry, we could not authenticate you. Please try again.