[openstack-dev] [tripleo] Facilitating automation testing in TripleO UI
akrivoka at redhat.com
Thu Aug 3 16:59:25 UTC 2017
Hi TripleO devs,
In our effort to make the TripleO UI code friendlier to automation
testing, there is an open review for which we seem to have some
difficulty reaching the consensus on how best to proceed. There is already
a discussion happening on the review itself, and I'd like to move it here,
rather than having it in a Gerrit review.
The tricky part is around adding HTML element ids to the Nodes page. This
page is generated by looping through the list of registered nodes and
displaying complete information about each of them. Because of this, many
of the elements are repeating on the page (CPU info, BIOS, power state,
etc, for each node). We need to figure out how to make these elements easy
for the automation testing code to access, both in terms of locating a
single group within the page, as well as distinguishing the individual
elements of a group from each other. There are several approaches that
we've come up so far:
1) Add unique IDs to all the elements. Generate unique `id` html attributes
by including the node UUID in the value of the `id` attribute. Do this for
both the higher level elements (divs that hold all the information about a
single node), as well as the lower level (the ones that hold info about
BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI
codebase with many `id` attributes that would otherwise not be needed.
2) Add CSS classes instead of IDs. Pros for this approach: no need to
generate the clumsy ids containing the node UUID, since the CSS classes
don't need to be unique. Cons: we would be adding even more classes to HTML
elements, many of which are already cluttered with many classes. Also,
these classes would not exist anywhere in CSS or serve any other purpose.
3) Add custom HTML attributes. These usually start with the 'data-' prefix,
and would not need to be unique either. Pros: avoids the problems described
with both approaches above. Cons: AFAIU, the React framework could have
problems with custom attributes (Jirka can probably explain this better).
Also, casual readers of the code could be confused about the purpose of
these attributes, since no other code present in the UI codebase is using
them in any way.
It seems that a perfectly optimal solution does not exist here and we will
have to compromise on some level. Let's try and figure out what the best
course of action here is.
Senior Software Engineer
Red Hat Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev