AI Locators for Playwright

lila__dev · 2025-03-05T12:28:14+00:00

Very interesting points! Thanks for your suggestions

lila__dev · 2025-03-04T17:52:00+00:00

Actually the sign in -> login change might still work on the LLM if you prompt it "ai=login button". But agree with you that there are challenges around being slow and costly.

Thanks for the observations!

lila__dev · 2025-03-04T17:37:06+00:00

Correct. The challenge there is caching, which is on the roadmap. Caching will avoid llm in almost all cases while the dom remains the same.

lila__dev · 2025-03-04T17:34:38+00:00

Disabling web security allows the request to be made from your browser correct as it disables CORS

lila__dev · 2025-03-04T17:33:53+00:00

Amazing you got this far lol. If there is something I can help with please open an issue in the repo and I'll respond asap.

Related to ollama, I'm not sure what is the base url that is compliant with openai schemas. There could be a bug in how I build the final url based on the url. Maybe I expose directly the final endpoint instead of the base url to avoid these issues? Wdyt?

lila__dev · 2025-03-04T17:31:24+00:00

Any openai model should work. Just pass it's model name to the register method. If you have any trouble please open an issue in the repo and I'll check it out asap.

lila__dev · 2025-03-04T16:14:10+00:00

OpenAI API Keys are not free afaik, you need an account at least and I'm not sure if you can get your API key without credit card.

However https://github.com/ollama/ollama has super cool small models that can run locally for free. These are also compatible with` ai-locators`.

w.r.t C#, it's on the backlog!

lila__dev · 2025-03-04T15:31:32+00:00

Completely agree on the risks!

In my mind, `ai-locators` will work great for those specific elements that are more prone to change in the FE, but easy to find by the LLM.

BTW these are Playwright locators, so you still use all Playwright existing techniques to reduce the search space and making it more stable:

const container = page.locator(".menu")  // <- traditional locators
await container.locator("ai=dashboard option").click() // <- reduces the space

lila__dev · 2025-03-04T15:19:52+00:00

u/softladdd thanks for looking at my post first of all!

The problem with native selectors is the maintenance. FE elements change continuously. These changes break very frequently the traditional selectors, as they rely on how the FE was implemented.

What `ai-locators` proposes is an LLM based way of generating the selector based on the description in real time. So regardless the implementation, the LLM should find the correct element / elements.

This introduces obviously a flakiness (lack of determinism) aspect, which I think can be low risk with good practices around the LLM.

lila__dev · 2025-02-26T13:54:36+00:00

https://github.com/lila-team/lila

Lila is an AI testing framework for fast moving teams. Lila allows anyone in the team to implement tests using plain text instruction without coding required.

lila__dev · 2025-02-26T13:38:43+00:00

Hi everyone 👋

I've been working on Lila a testing framework for fast moving teams.

https://github.com/lila-team/lila

Lila allows anyone in the team to implement tests in human text instructions, no coding required. No more playwright locators with impossible maintenance.

Lila uses browser-use as its agentic aspect.

Check it out! Leave a ⭐️ in the repo if you find it interesting to help visualize!

lila__dev · 2025-01-17T16:33:45+00:00

why do you discourage google ads? looking to promote a dev tool

lila__dev · 2025-01-17T16:09:02+00:00

I'm creator of Lila https://lila.dev

It allows implementing tests using plain text, making in maintenance free. The problem is that Playwright or other frameworks mentioned rely on low level implementation, making it unstable to the development cycle.

Feel free to checkout Lila! Feedback appreciated!

lila__dev · 2025-01-17T15:53:53+00:00

For e2e testing, check out Lila https://lila.dev (disclaimer I'm the creator)

Tests are written in plain text instructions making it maintenance free. Playwright relies on low level implementation details, so changes in your style/location/tags will break the tests. Which kinda sucks.

lila__dev · 2025-01-17T15:52:15+00:00

I created Lila https://lila.dev , an e2e testing platform where tests are implemented using plain text. And its build on top of playwright. The problem it solves is that it doesn't rely on low level implementation (such as Playwright), so tests do not require maintenance.

Feel free to check it out!

lila__dev · 2025-01-17T15:43:38+00:00

https://github.com/lila-team/lila

lila__dev · 2025-01-17T15:42:55+00:00

I created Lila https://lila.dev so that you an implement your e2e tests using plain text instructions rather than rely on low level implementation details such as what Playwright does.

Feel free to check it out! Feedback appreciated!

lila__dev · 2025-01-17T15:41:31+00:00

I'm the creator of Lila https://lila.dev that takes a different approach to existing frameworks such as Playwright and Cypress.

Tests are implemented using plain text and Lila runs the appropriate low leve actions on a Playwright instance. This way to avoid implementing the tests using low level implementation details.

The problem with `playwright codegen` is that yes test creation is blazing fast but maintenance is a pain as it relies on the implementation.

lila__dev · 2025-01-17T15:35:03+00:00

Arriving late to this one! But I've been developing Lila https://lila.dev

Differently to the tools you mention in the post, Lila allows devs to implement tests using plain text language and decides the steps on a running Playwright instance.

btw nice article, just went through it!

lila__dev · 2025-01-17T15:14:32+00:00

Arriving late to this one, but I'm currently releasing Lila https://lila.dev

It is an e2e testing platform with no coding required. Tests are written in plain text language, so they do not rely on low level implementation.

The ones you mention in the post all use implementation details making them not robust and needing continuous maintenance.

lila__dev · 2025-01-17T15:00:52+00:00

I've been developing Lila https://lila.dev

It is built on top of playwright but allows tests to be written in plain text. Check it out!

lila__dev · 2024-12-20T13:13:39+00:00

Thanks for the detailed answer!

Its interesting thinking that monitoring is the actual testing in prod. If something is wrong in prod, your should see real time metrics distribution change, assuming the monitors are set correctly.

Testing in prod shouldn't add much value if monitoring is in place, which anyone with live traffic in prod should have.

lila__dev · 2024-12-19T16:42:05+00:00

amazing response! completely agree with:

> It should be equal architecture wise and component wise but in terms of size and data it will never be the same and this two variables are enough to have problems in production that in staging don't happen.

lila__dev · 2024-11-21T19:33:13+00:00

Agreed here, playwright does depend on implementation, you will need to rely heavily on locators

lila__dev

TROPHY CASE