[Cosmo-dev] Getting a handle on specific UI elements

[Matthew Eernisse]

Seems like we have a pretty good idea of the benefits and drawbacks of 
the system that Bobby is proposing -- creating a separate namespace for 
UI elements that we would be using solely for DOM-node ids attributes.

The other alternative I originally had in mind would be for QA to 
leverage the existing JavaScript namespaces / object chains to get a 
handle on specific UI elements' DOM nodes, and grab the id attribute 
from there.

Here is the cost/benefit breakdown for that approach as far as I can see.

Benefits

1. Less maintenance

By using the exiting JS object chains, we wouldn't have a second 
separate namespace to keep up-to-date with changes to the code.

2. More power and flexibility

Directly interfacing with the JS code gives them a broader array of 
things they can test, because they'll have handles on the logic elements 
(or widgets, if they exist), rather than just pointers to DOM nodes.

In fact, simulating user events on UI elements is only one of the ways 
QA will be testing. For other things (e.g., pulling form element input 
-- DetailForm.form.recurrence.value), they'll be using the JS object 
hierarchy directly anyway.

3. Doing things consistently

In addition, there are UI elements like the event lozenges which may 
appear in variable numbers or positions. Just like form input access, 
using the existing JavaScript code is the only approach.

4. Scriptable testing

Doing everything in JavaScript, and making the testing uber-scriptable 
seems to be kind of the entire point of the approach we're taking with 
testing.

Doing all of that in plain JavaScript -- instead of stepping outside 
that and inventing a new system just for DOM elements -- seems more in 
line with that approach.

5. Open access

Having QA more deeply involved in the UI code has the ancillary benefit 
of giving us more people who are familiar with the code.

To do any of the AOP-style performance testing of the UI code, there 
will have to be people in QA with a high degree of familiarity with the 
UI code in any case.

Drawbacks

1. Changes in implementation

Leveraging our JS code would require cooperation between QA and the 
developers, to ensure we don't break scriptable access to UI elements in 
the development process.

2. Ensuring access

This approach would require that any UI elements which QA needs to touch 
have an addressable path in the JavaScript object hierarchy. There may 
be cases where we have to add a link in the chain somewhere, or make a 
member of a JS object public instead of private to give QA access to it.

I think that's it, as far as I can see. I'd appreciate feedback. I'd 
really like people who haven't chimed in yet to give us a little input. 
Specifically, since QA will be working with this, could y'all give us 
some feedback on this?


Matthew