[lfryc]

Can't you use List<? extends WebElement>?

[jhuska]

Another interesting topic related to Page Fragments refactoring.

Jirka has found out an efficient way how improve speed of Page Fragments. It is by using of JavaScript API, instead of WebDriver interactions.

So for example when working with r:calendar, specifically setting of the date. Instead of tedious process of clicking on the image button to invoke calendar, selecting date, ... via WebDriver, we can call calendar JS API to set the date.

An example of this can be seen in this commit: https://github.com/richfaces/richfaces-qa/blob/e74b7fc02304e9e6cff1971a98c9894087ac7b81/page-fragments/src/main/java/org/richfaces/tests/page/fragments/impl/calendar/RichFacesCalendar.java#L73-L101

However, we can predict some troubles when going in this way. As Lukas pointed out, we will not do functional testing anymore. The behavior of the component can be unpredictable. (e.g. can we guarantee that onchange listener is invoked when the date is set in this way ?)

In the same time, we do believe, that it can be used with caution. That user of such Page Fragment should have a possibility to choose what way of interactioins he will use:

• e.g. fast JS way for headless smoke tests in the cloud
• and the WebDriver way for other tests

I have filed feature request which propose a way how to solve this with support of Graphene.

https://issues.jboss.org/browse/ARQGRA-325

What do you think guys, are we missing something here ?

[lfryc]

As we have discussed this with Juraj in a persona, I would like to provide you with a more context:

you can either

1. write tests which will simulate exactly what end-user of a tested application does

2. write tests which will interact with an component/widget API using JavaScript

• + it's faster
• + more reliable
• - it's not "real"

The question is what would final user of Page Fragments appreciate more

and if implementing both principles and let one choose the best approach depending on situation?

[lfryc]

With simulating real interaction, you can discover more bugs in the implementation. -> real

But lot of people assumes that detailed testing is done by upstream project, so they don't need to care about it too much. -> JS API

However when you are not simulating user interaction then you have still need to do lot of manual testing since you can't be sure everything works together as a final product. -> real

----

Using JS API approach simulates rather processing of a value by the application logic - it can be JSF or JavaScript or any other implementation.