Provide support to directly select "Testers"

[mstahv]

The current $ method returns actual Vaadin component instances. Testing via those is sometimes the easiest way, but may also cause "unexpeted" things. The primary way we should advocate would probably be via "Tester" APIs. Thus it would be handy if the "locators" (currently the $ thingie) could directly return "Testers". The component instance could then be aquired via tester or via separate API 🤷‍♂️

Note, I have not fully inspected the implementation so this is not a "finished plan", but more like an observation that "we should do somethign for this".

[StefanPenndorf]

This would break backward compatibility. I think your proposal will be the best solution but if backward compatibility is a concern maybe you'll think about a slightly more cumbersome solution:

ComponentTester<> dialog = $(Dialog.class).singleAsTester();

ComponentTester<> closeButton = dialog.find(Button.class).singleAsTester();

This is not ideal but keeps compatibility. This solution would also have the advantage that only a single new method would be needed in ComponentQuery.

Of course you need to decide if there should be also a *AsTester variant for last(), id() and atIndex().

I'm not sure if also list of ComponentTester should be supported. If Tester API should be advocated as primary interaction API this will be a must, too.

[mstahv]

That's a viable idea👍 I think we should try to build couple of variants and see what are the technical constraints and how does it feel in action then.

[mcollovati]

The main challenge here is to provide a type safe API that's also not verbose.
For example, the proposed snippet returns a ComponentTester that in most of the cases is a bit useless.
You'll need a DialogTester to test your dialog component and so on.

There are tricks like <T extends ComponentTester<...>> singleAsTester() but this delegates to the caller the responsibility to specify the exact tester type. The same goes if the tester class is given as an input parameter to singleAsTester().

The problem is not getting the correct tester at runtime but providing a nice API that allows code like test(dialog).hide() instead of

// all example leads to potential class cast exception,
DialogTester dialog = $(Dialog.class).singleAsTester(); 
// or
DialogTester dialog = (DialogTester)$(Dialog.class).singleAsTester();
// or
DialogTester dialog = $(Dialog.class).singleAsTester(DialogTester.class);

The benefit of test(componentInstance) is that you don't need to know which tester you have to use, the API already provides you with the best one for each case (at least for Vaadin components)

To directly operate on testers, I guess we need a completely new API that incapsulates ComponentQuery instead of exposing it.
But this way, the users have to decide beforehand which tester they want, and the API should restrict the search to compatible component types. Basically we revert the logic.
This kind of approach would be similar to Testbench API.

$(DialogTester.class).withAttribute(...).single().hide()
// or (probably not working) 
$(DialogTester.class, query -> query.withAttribute(...).single()).hide()

[mstahv]

PoC:ed this in #65

[mstahv]

Fixed with a slightly different approach by #65, this can now be considered as fixed.