This is an awesome initiative - I have a feeling the Component Objects feature is going to be a hit! Encapsulating the DOM of widgets/components/page-fragments, and creating an API for that fragment which is re-used accross multiple tests will dramatically increase the durability of tests when changes are introduced. So you changed that div to a section in your component and all your tests break? Simply update the Component Object to reflect the DOM change and the tests are all fixed. Pure awesome!
I do agree however that the term Component Object is too generic and doesn't convey well the intent of the pattern. Components are Objects so the redundancy of the term leads to additional confusion. OTOH, you are creating objects for testing components so I can see where the name came from. One thing to keep in mind is this same pattern can also be used for more than just components. For instance I can include a login or search fragment on a number of pages (using ui:include, or ui:composition/ui:insert in JSF) and this same pattern would be useful in encapsulating the details of the DOM.
Some ideas for names (none that I am too excited about - but maybe they will inspire a better suggestion from others) are:
- Component Testing Objects
- Page Fragment Objects
- DOM Objects
Actually, DOM objects plays well with the already established Page Objects name...
Very nice. I forsee RichFaces providing TestComponents for their Component suite for reuse by users..
Aslak, that is indeed one of our goals. The RichFaces QE team is working towards creating the Component Objects for the RF components that we will use for our own tests, as well as making those Component Objects available to RichFaces users for testing their applications.
I like Page Fragment objects (for reusable DOM encapsulation),
but I have also concerns it does not pretty well fit with objects for testing widgets:
"There is a Page Fragment for testing Autocomplete widget" - sounds silly
What about Page Components? The components being used in a page.
Page Components could be an additional concept, which does not have a specific Graphene API (using Page Fragments internally) -
it rather introduces encapsulation for well-known widgets.
Then, we could have two concepts presented:
* Page Fragments - feature of Graphene, improvement over Page objects
* Page Components - encapsulation of well-known components
Thanks guys for your opinions.
IMHO two concepts is quite a lot for a project which is quite difficult to differientate from the similar Page objects pattern. It will be also more convienent for people to deal only with one concept.
That is why I am for one concept with generic name. The name which will stand for both well know web components and other parts of the page (widgets, gadgets, aspects, fragments, ui:includes, ...).
From your proposals I like for example Page Fragments (Autocomplete is also fragment of the page, that is why you can have Page Fragment to test it).
At the same time I do feel that I am not experienced enough as you guys are, so I am pleased to get advise from you.