- Selenium test case demonstrating their use in simple workflows.
- API test demonstrating they work with nested workflows from the run perspective.
- Update run variant of workflow to_dict to parse out replacement parameters to display on the backend and tweak the client to just accept these.
- Parse out replacement parameters for subworkflows recursively, include in new run output attribute - nested workflow replacement parameters work now.
- Selenium test case demosntrating subworkflow replacement parameters are rendered and used when submitted.
Allow the rules DSL & GUI component to operate on existing collections to allow filtering, sorting, modifying identifiers and general re-organization of existing collections (e.g. the outputs of tools). Implementing this as a collection operation tool so that it should be executable interactively in the tool form and in a batch fashion as part of workflow executions.
For this to be tracked properly as a tool execution and to work properly in the tool form, I've implemented a new tool framework and tool form parameter type called "rules".
This can thought of as a more GUI friendly alternative to my proposed collection operations that consumed JavaScript expressions.
This includes API tests for both tool and workflow execution of the new tool as well as Selenium tests for tool form execution, workflow editor interactions, and workflow running.
Re-use test_data specification used by many of the API workflow tests and a workflow used by another test. Add abstractions and DOM element for mapping labeled test data to tool form inputs.
- More stuff tested:
- Connecting and disconnecting simple terminals as well as mapping terminals (ribbons).
- Rendering simple workflows, workflow with output collections, workflow with mapping, and workflow with a subworkflow.
- Collapsing side panels in the workflow editor.
- Small tweaks to editor DOM.
- More screenshots.
Implement different "WAIT_TYPES" and try to sleep for different amounts of time based on what is being waited for.
Replace sleep statements in addition to Selenium wait on statements.
This test went from transiently broken to always broken during this release cycle. This PR makes two changes to try to fix both of those conditions. It correct the frame and button Selector for the new workflow run UX for the newer error and this allows explicitly refreshing the browser when waiting for datasets to appear to deal with the transient problems.
This time for the workflow upgrade message test, mirrors the fix in #4524 - the content we are searching for in on this page is no longer in the iframe.
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.)
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.
Nicola Soranzo