[HN Gopher] Show HN: Donobu - Mac App for Web Automation and Tes...
___________________________________________________________________
Show HN: Donobu - Mac App for Web Automation and Testing
Been working on a desktop app for Mac that lets you create web
flows and rerun them (https://www.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
Author : wewtyflakes
Score : 60 points
Date : 2024-10-09 16:18 UTC (6 hours ago)
(HTM) web link (www.donobu.com)
(TXT) w3m dump (www.donobu.com)
| pavlov wrote:
| Such a nice, simple landing page. I could immediately understand
| and appreciate what this app does by first looking at the picture
| where the flow is defined, then seeing the flow executed on
| video.
|
| It's like the old Apple commercial: "There is no step three."
|
| Congratulations on the launch!
| rexreed wrote:
| Interesting! How far away is this tool from being a desktop
| simple RPA solution? Would it be able to interact with desktop
| apps and simulate mouse or keyboard actions in the future?
| wewtyflakes wrote:
| Right now we are constrained to using the DOM of webpages. This
| is because we need some reasonable way to detect what parts of
| a UI are interactable or not (though we do some magic to do
| this); this would be a bigger challenge for arbitrary desktop
| apps. Also, there would be new security aspects that would have
| to be meticulously considered if we were to allow an agent to
| control arbitrary desktop apps. Constraining the agent to the
| browser has nice alignment in this way.
| sahmeepee wrote:
| Playwright (and axe) is a good option, but how do I have
| confidence it's performing the test correctly and repeatably? If
| the test seems flaky how do I know it's the software and not
| randomness of the AI part? I want tests to be predictable.
| wewtyflakes wrote:
| For running the axe test itself, once the agent has decided to
| run it, is a dedicated tool to run an off-the-shelf axe script.
| The axe script itself does not change from run to run, so
| assuming you are running the test on the same page, you should
| get the same result.
| sahmeepee wrote:
| The axe element will be the same each time, but you can do
| that without any AI shenanigans - just run it in a normal
| Playwright test.
|
| 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.
| wewtyflakes wrote:
| We are going to be adding the ability to trigger more
| actions (beyond the normal clicks/keyboard) without AI by
| using the in-browser control panel. We wanted to add it for
| this ShowHN, but we ran out of time on our self-imposed
| deadline. :(
|
| 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.
| bkyan wrote:
| Is there anything in the tech stack that make this app specific
| to Macs, or are you simply rolling this out to Macs, first?
| wewtyflakes wrote:
| We're rolling out to Macs first since that is what our
| development environment has been, though nothing is stopping us
| from supporting Linux or Windows once we have those
| environments properly set up. It is on the near-term road map!
| mattfrommars wrote:
| Just to be clear, did you really decide to use Java to build a
| desktop application for Mac? I see you mentioned Java 21 as main
| business logic layer, which technology did you use to build the
| desktop application?
| wewtyflakes wrote:
| We really did! :) Though, there were some unfun challenges
| around that, like getting distribution to work without having
| to get people to go through the pains of installing the JDK.
| Thankfully, since our UI is just a web browser, we did not have
| to go down the path of JavaFX or anything like that; our UI is
| just plain JS/HTML making API requests to a propped up server
| on localhost:31000 (for the curious).
| asabla wrote:
| This looks really interesting and could really be a nice addition
| to my daily work.
|
| 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
| wewtyflakes wrote:
| Thank you for the direct actionable feedback, we will improve
| that messaging.
|
| 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).
___________________________________________________________________
(page generated 2024-10-09 23:00 UTC)