I once worked at a company with 1000 UI tests. Every PR tests would fail because certain backend failures would cause flaky behavior. Then, we started mocking response, and of course they no longer failed. They also no longer caught real bugs anymore. Does that give you some nuance?
First of all, I didn't make this, let me be clear, and I don't work for the company Mobile.dev.
I've been looking for a replacement for Appium because the documentation for that site is absolutely garbage. Maestro boils everything down to YAML and runs its own test server so that you don't have to worry about connecting to the device drivers. It's missing an API but who needs an API when the CLI is so beautiful.
Does anyone know of anything on par with this that I should try? So far this has knocked my socks off.
Co-author of Maestro here - really appreciate that support jztan! If you get a chance you should also try out web support which we recently released! And always open to feedback, so please let me know if there's anything you think can be improved!
Hi Jztan, glad you're exploring this space! I'm the co-founder of MobileBoost, and I'd love to introduce our product, GPT Driver (https://www.mobileboost.io/).
We started two years ago with an AI-native approach, which is particularly useful for handling dynamic flows, hard-to-locate UI elements, and testing across multiple platforms and languages. Our main objective is to reduce test maintenance effort.
We offer:
a Web Studio – A no-setup-required platform with all tooling preconfigured.
SDKs – Directly integrate with existing test suites (Appium, XCUI, Espresso).
Yes, you can use our SDKs to run it locally on Simulators, Emulators, and real devices. We also support popular third-party device farms via the WebDriver protocol.
By default, the SDKs use our API endpoints, where we run a combination of models to maximize accuracy and reliability. This also enables us to provide logging with screenshots and reasoning to help with debugging.
That said, we're currently experimenting with a few customers who run our tooling against their own hosted models. While it's not publicly available yet, we might introduce that option going forward.
Would love to hear more about your use case, if a self-hosted setup is relevant or just the use of your own LLM tokens?
We will have AI-suggested corrections in the near future! There are a lot of applications for AI here around structure and understandability of an app for the accessible user. We also plan to increase rule coverage to as many WCAG rules (78 total) as possible, starting with the most common offenders.
Hi! Sharing a product after many iterations on its UX (with more rule coverage coming soon).
I stumbled upon this problem when the company I was at faced an accessibility lawsuit and needed engineers to fix them. Though there were accessibility champions, I fell into the category of average engineer who had very little experience with correcting/testing these tickets.
With jargony documentation of accessibility guidelines and bad descriptions from audit, it was very frustrating to work with. I could not easily fix them without seeking help.
My friend Michael and I started working on this problem and are excited to launch:
TestParty’s first product is a VSCode extension called Pregame. It scans your code inside the IDE and provides code suggestions for accessibility violations. In your side bar, you will see why it fails/passes guidelines and gives you some accessibility training in-context. The link below is the direct link to the VSCode Extension:
I know most scanning tools take this route, but I personally only enjoy using scanners that auto-fix my mistakes.
In your example of an image not having an alt text, instead of blocking me from shipping, I'd prefer it if used an ML auto-captioning tool to suggest a caption (and even offer translations) so I can move on with my commit.
Great suggestion! We will include ML-based corrections for individual developer mode very soon. For others, even a sign post is helpful. The translation point is a great one that we are also excited to work on.
reply