Assign unique IDs to UI elements as handles for automated testing

Have added IDs in most places in UI modules.

Have updated stripes-core to set IDs for each app's navigation button, for the app's main display and for login and logout.

Have documented conventions (in so far).

Assigned unique ID to user search field as per John C's instructions above and changed ui-testing to look for that.

Troubleshooting why UI tests succeeded on folio-testing.aws while failing locally.

Current folio-testing.aws uses stripes-components 1.3.1, which I guess is pulled in by stripes-core 2.3.2-SNAPSHOT.676.

Local stripes-demo-platform references stripes-core 2.3.1 and stripes-components 1.3.0

Consequently, the tests in ui-testing could not successfully test against both environments.

By switching to npm-folioci, you can pull stripes-core 2.3.2-SNAPSHOT.676 and thus get stripes-components 1.3.1 and the test that previously failed locally then passes.

Discussed element IDs with John C, as he is changing certain buttons to anchors.

As long as they are referred to by ID and retain that ID, it should work. However, if the ID indicate that the element is a button – like id='button-edituser' – then that could be confusing. A more generic ID, like id='clickable-edituser' would be better (if the ID should be anything but a completely opaque string but opaque IDs, I guess, would be confusing too, for instance when reading test scripts).

Now, this raises a different question, of the dependency management between UI modules and ui-testing. If the element IDs are changed, tests will break until the tests themselves are updated too (or vice versa). If I change both at the same time, will they both end up in our automated test setup with a relative short gap of breakage?

Note to self: Developer documentation about setting element IDs