At the insistence of @nsoranzo, be more explicit about waiting for workflow test in API tests. While I was in there I also setup new abstractions for waiting on state and updated various workflow cancelling tests to use test_history context for better error reporting.
I saw a failed test earlier that would have been fixed by a switch to wait_for_and_click in workflow_editor_click_options. This makes that switch and moves some of these workflow editor helper functions into navigates_galaxy.py for reuse by other test cases and by library users.
Previously just a notification about waiting for ``a.loggedin-only`` failed would show up. This doesn't indicate if the login failed completely or the masthead just failed to update. I suspect the login failed completely, but just in case I've updated the error handling to actually ping the API and check and print a better error message with this information.
New messages look like:
```
TimeoutException: Message: Failed waiting for masthead to update for login, but user API response indicates [test0ol61vs8fo] is logged in. This seems to be a bug in Galaxy. API response was [{u'username': u'test0ol61vs8fo', u'quota_percent': None, u'preferences': {}, u'total_disk_usage': 0.0, u'deleted': False, u'id': u'adb5f5c93f827949', u'nice_total_disk_usage': u'0 bytes', u'quota': None, u'email': u'test0ol61vs8fo@test.test', u'is_admin': False, u'tags_used': [], u'purged': False}].Timeout waiting on CSS selector [a.loggedin-only-x] to become visible.
```
and
```
TimeoutException: Message: Failed waiting for masthead to update for login, API indicates no user is logged in - there is a problem with this test. API response was [{u'quota_percent': None, u'nice_total_disk_usage': u'0 bytes', u'total_disk_usage': 0}]. Timeout waiting on CSS selector [a.loggedin-only] to become visible.
```
- set_tags() appeared in both published and saved history tests, refactored into navigates_galaxy with function name history_panel_add_tags
- is_displayed() appeared in both published and saved history tests, refactored into has_driver as selector_is_displayed
- Introduced history_panel_rename to reduce duplication across history panel tests and newer published and saved history tests.
- Removed custom history click option helper in saved and published history tests and just used the variant in navigates_galaxy.
- use wait_for_and_click a couple more places...
- Be sure when sharing a history with a user we wait to actually see that user's e-mail address appear in the history's sharing list after submission.
- Print something for the failed history sharing assertions (I'm pretty sure they are 403 errors because some aspect of the sharing or login didn't work - but might as well verify).
Locally this never happens, but remotely sometimes when sorting by owner the histories are sorted by owner but not in the same order as the test was asserting. I would assume this is likely a postgres vs. sqlite difference - perhaps the former doesn't sort the rows by the order they were created within equal sort classifications (i.e. same owner) but the latter does. I've fixed this - the test should not have been asserting such a strong condition I don't think.
I switched to randomly generated usernames without actually ensure the random usernames would be generated in the same lexiographic order - that wasn't super bright of me. That sort by owner test should pass as frequently as the other tests in that test case class now.
There are a few different transiently failing tests on Jenkins that seem to fail because the test thinks Galaxy is logged in but it is not. So now after we click the login button in Selenium - we will wait for to see the "Register or Login" button turn into the "User" button.
This is a similar problem and fix to what was done in #4562 - which seemed to help.
The the [latest Selenium test execution](https://jenkins.galaxyproject.org/job/selenium/212/testReport/) most of the published histories tests failed. It looks like this is because of the three histories that were supposed to be published, only 2 were actually published. My best guess for what happeend was that the click of the button to publish the history occurred but the next Selenium command happened so quickly that the page had not gotten a chance to respond to the click. This tweaked approach to publishing histories ensures we stay on the page until the "unpublish" link appears - this will either fix the problem or rule this theory out as the explanation.
Rather than depend on something in ``functional`` test module from ``base.driver_util``, just set these global hacks up in ``driver_util`` itself. This eliminates a dependency of ``functional`` on ``base`` - ideally ``base`` would not depend on any other test modules.
Dannon Baker