Problem. The locators are testers with their own vocabulary, not proxies of
the components — getSelected() not getValue(), selectItem(String) not
setValue(T), getSuggestions(), open()/close(). That's a defensible design,
but the vocabulary is undocumented per component, so the discovery loop is:
guess a method → compile error → javap the jar → find the real name.
unzip -o browserless-test-shared-1.1.1.jar -d /tmp/bl
javap -p -cp /tmp/bl com.vaadin.flow.component.textfield.BigDecimalFieldLocator
Cross-cutting helpers are the worst hit: Locator.inside(...), atIndex(int),
withCondition(Predicate), withClassName(String...), invalidate() and
components() are all useful and all invisible unless you read the base class.
Ask. Publish the locator surface in the browserless testing docs — a table of
findX() → locator → its methods (generated from the source, so it can't drift),
plus a page on the base Locator filters. Failing that, ship
-sources/-javadoc jars prominently enough that IDE completion carries the
docs.
Copied from https://github.com/vaadin/agentic-dx-improvement/issues/107
Problem. The locators are testers with their own vocabulary, not proxies of
the components —
getSelected()notgetValue(),selectItem(String)notsetValue(T),getSuggestions(),open()/close(). That's a defensible design,but the vocabulary is undocumented per component, so the discovery loop is:
guess a method → compile error →
javapthe jar → find the real name.Cross-cutting helpers are the worst hit:
Locator.inside(...),atIndex(int),withCondition(Predicate),withClassName(String...),invalidate()andcomponents()are all useful and all invisible unless you read the base class.Ask. Publish the locator surface in the browserless testing docs — a table of
findX()→ locator → its methods (generated from the source, so it can't drift),plus a page on the base
Locatorfilters. Failing that, ship-sources/-javadocjars prominently enough that IDE completion carries thedocs.
Copied from https://github.com/vaadin/agentic-dx-improvement/issues/107