Thanks Walden for bringing this up. Dne středa 29. listopadu 2017 20:06:50 CET, Walden Raines napsal(a): > > Seems reasonable to me. I don't really see a downside other than the work > > to add all the IDs. > > I don't think we should go through the entire application and add the IDs.
Why not? It might be a bit boring but very useful effort. If we only add IDs to new UI, I as an integration tests writer would remain frustrated whenever I add new test that touches existing area. I think it wouldn't be more than 1 day of work to extend all tables in Foreman core. For inputs it should be even simpler as we have form helpers that would just need to be updated (but I think all rails inputs already have id). This would also be a good opportunity for a contribution for someone who'd like to investigate the whole stack, go over all pages and do small code changes on them. > I think the way to tackle this is two-fold: > > - Add IDs as we update functionality on pages that don't have these IDs > - Encouraging QE to report missing IDs (and potentially open a PR to add > them) on troublesome pages > > The latter has already been agreed to, the former is in our hands to > remember to do. I think we should also agree on a guideline how to construct such IDs, so we don't end up in random strings which would be prone to duplicates. For parts that are generated by rails, I think using dom_id helper would be a good start [1], obviously UI rendered from JS would need to have it's implementation of this method. For tables we could have something like this 'table-users' for tr, this should do dom_id(user, 'row') # result is row_user_15 where 15 is id of user, or row_user if user is new_record For inputs, rails follow the rule $resource_$attribute, while this does not necessarily need to be always unique, I think it's a good enough for resource forms. For the rest (e.g. search input) we should generate it uniquely, there are cases where we have 2 search field on the same page, e.g. roles and filters opened in 2pane. For buttons it can be tricky. Perhaps the same approach as we have with data- id today in core would do, or even keep to data-id only. [1] https://apidock.com/rails/ActionView/RecordIdentifier/dom_id -- Marek > > Cheers, > Walden > > > On Wed, Nov 29, 2017 at 1:31 PM, Ewoud Kohl van Wijngaarden < > > [email protected]> wrote: > > On Wed, Nov 29, 2017 at 01:08:13PM -0500, Walden Raines wrote: > >> In order to assist in UI automation, I would like to propose that we add > >> > >> unique IDs to the following elements: > >> - Tables and table rows (<tr>s) > >> - All inputs, including those not technically in a form (row select > >> checkboxes, for example) > >> - All buttons > >> > >> These IDs should all follow the same format, perhaps something like > >> object.class-object.id-element.type. For example, product-2-row and > >> product-2-checkbox. > >> > >> Thoughts on this? Anything that needs to be added or changed? > > > > +1 This was also the feedback I heard from QE. Sometimes they have to use > > xpaths to test which are more likely to break than IDs. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
