PR #3992 fixed "with self.main_panel()" so that leaving the context actually restore the Selenium context back to the top level page. This surfaced a bunch of bugs related to assertions that were operating in the main panel without declaring it. This fixes those and makes the assertions a bit stronger - such as verifying error messages being asserted about are visible.
- By default this won't occur locally, but you can set GALAXY_TEST_SELENIUM_RETRIES to a non-zero number to enable auto retrying tests that many times.
- Capture the stack trace in the Selenium test error report directory - this will be useful for debugging problems that may fail once but pass on a subsequence attempt. Jenkins now captures these directories and includes their content in the test reports.
- Document the Selenium test error report directory in run_tests.sh as well as this new retry variable.
- Update the Jenkins test script to set this new variable to 1 so transient failures break the build much less frequently.
The ``with self.main_panel():`` construct wasn't cleaning up properly - I've fixed this and eliminated the terrible workarounds in the execution test case that I guess I had added trying to figure out how to make things work. It should be more stable now. (This test case has been failing 1 out 9 times I'd say.)
- New upload tab for "Collections".
- This has a new option to select "Collection Type" in footer.
- Collection upload geared toward homogeneous datasets - must specify genome and file format for all files.
- New button "Build" after all individual datasets have finished their upload to the server.
- Clicking "Build" launches the appropriate collection builder for selected collection type.
- By default, uploading a collection hides the original uploaded datasets (can be unchecked).
Implement tests for all uploaded collection types.
This includes two parallel changes to the Selenium tests.
- It adds a decorator to allow retrying certain atomic actions that may occur during jQuery transitions automatically.
- It refactors things to allow waiting on HIDs to become visible instead of just green.
- Use newer abstraction in the simplest upload test - verify the default extension (auto -> sam) and dbkey (?) also.
- Add a test case that explicitly sets the extension of an upload and verifies.
- Add a test case that explicitly sets a genome and verifies.
- Add a test case that tests setting ext for all uploads and verifies.
- Add a test case that tests setting genome for all uploads and verifies.
See code comment for more information - I am tracking the issue here https://github.com/galaxyproject/galaxy/issues/3598. I think it is important to resolve that test and fix the usability problems with current tours but I'd like to get the Selenium tests stable and testing against new PRs first.
I'm pretty sure the problem is that I was waiting on conditions (e.g. datasets to become "ok") using the API and then assuming the state of the GUI elements was the same. Obviously though the GUI is polling the API and there is some lag there. This commit changes things to specifically wait on history panel GUI changes - obviously the better thing to wait on in a GUI test.
Expand and then break out workflow management tests into its own file since these aren't related to the workflow editor per se. Includes new tests of workflow "viewing" and "renaming".
Add a new file for testing workflow execution. This currently contains tests for simple execution with a single input and a test for running workflows with tool version upgrades.
This includes a refactoring of some existing tests related to checking various things in the history panel - as part of building up good history panel abstractions. The previous constructs were ported fairly literally from older CasperJS tests. These abstractions therefore referred to everything has "hda"s instead of history items. The newer abstractions therefore allow for collections and are built around HIDs (a visual thing exposed to the user) instead of HDA IDs. I think this is higher-level and more appropriate for a web functional test.
Rebase into workflow GUI tests.
- Test parameters and tables appear on dataset details page after running a tool.
- Test a simple tool execution with an integer field.
- Test re-run a tool.
- Test a tool with a data drop down.
- Improved select2 abstractions.
See documentation added to run_tests.sh. This can be configured to target local web browsers or Selenium remote services as detailed in that script.
Individual tests can be executed with nosetests directly or groups of tests can share a common test Galaxy spin up when using ./run_tests.sh. If GALAXY_TEST_EXTERNAL=<url> is set - it will be respected and Galaxy will not be spun up (remember the URL needs to be reachable from the Selenium server inside the Docker container).
Every test failure writes a current screenshot of Galaxy to database/test_errors.
I will be honest that the desire to move toward selenium is based solely on failing to get the Casper tests to pass consistently due to bugs causing segfaults in the underlying tools (probably casperjs or phantomjs?). Over the past year I have tried multiple versions of dependencies, etc... and it never works out for me. Likewise Martin has never been able to get the tests to run consistently under Jenkins. I don't think Python or JavaScript is inherently better, this wasn't based on a personal preference about what kind of test I want to write.
Despite this being the primary reason, there are clear benefits to Selenium. It tests the actual web browsers we support, generates screenshots, has better documented and more robust tooling, can scale across clusters. Less clear, but certainly still a benefit of being Python based is that it fits with the rest of the test framework more cleanly than CasperJS.
Finally Carl's last words on CasperJS were "Ditch it".
The following specific tests were added or replaced:
- Implemented tour testing via Selenium (walk the two working stock tours and verify elements avaiable and clicks are valid). This is how I discovered #3206.
- Added completely new workflow GUI test (basic creation from URL and in editor).
- Replaced broken CasperJS registeration tests (text and expectations now wrong) with a Selenium variant that works against dev.
- Replaced broken anonymous history CasperJS tests with working Selenium tests.
- Replaced broken upload CasperJS tests with working Selenium tests.
- Replaced history options CasperJS tests with Selenium tests.
- Replaced login CasperJS tests with Selenium tests.
- Replaced history-share-tests.js with test_history_options.py
- Replaced history-panel-tests.js with test_history_panel.py
- Replaced a big part of hda-state-tests.js with test_history_dataset_state.py
I'm confident these utilities represent a sharable and higher-level abstraction around functional testing of Galaxy that can be used outside of Galaxy's testing framework. So a subset of the functional test stuff is in a separate module with minimal dependencies that I intend to make stand alone and pip installable like galaxy-lib.
This module consists of:
- Sizzle stuff in its own package. This code allows Selenium to reason with jQuery selectors instead of vanilla CSS selectors.
- Functionality for creating a Selenium driver and virtual display.
- The ``HasDriver`` mixin - this provides higher level navigation utilities not specifically tied to Galaxy.
- A package with abstractions for navigating Galaxy. This provides a higher-level interfactor for things such as logging in and out, registering a user, navigating menus, fetching Galaxy style tooltips and error messages, and walking Galaxy tours.
In order to demonstrate this new module is useful outside of Galaxy tests - I've included a CLI package to ease building argparse utilities around these abstractions and implemented a simple demonstration script that walks a Galaxy tour and dumps screenshots of Galaxy at each step to a folder. This is more of a demonstration of the utilities than an actual polished end user tool - though it might be helpful in linting and debugging tours.
In the future I hope to extend this scripting to implement
- Periodic deployment testing to ensure things like Jupyter work in production.
- A best practice recipe for Galaxy QA testing by deployers.
- An utility to generate dozens of screenshots of various aspects of Galaxy so we can quickly visually inspect ever part of the GUI before big releases.
xref https://github.com/galaxyproject/starforge/pull/115 xref #1419
anuprulez