test: squish gui submitter job bundle test suite

[rena-cheng]

Fixes: N/A

What was the problem/requirement? (What/Why)

Test Case Automation:

We are lacking UI tests for the Deadline GUI dialogue, and this PR adds a test suite for verifying that job bundles are being loaded correctly via the Deadline GUI using Squish automated framework.

The main test flow verifies the Load a different job bundle button/functionality, ensuring that Job Bundles are being loaded correctly without issues in the Deadline GUI. Artists/devs/technologists will then use job bundles in the Deadline GUI to submit jobs to the render farm for processing. The test steps are as follows:

• Launch 'Choose a job bundle' directory using deadline bundle gui-submit --browse command and select an existing job bundle (named 'Job Bundle One').
• Verify Job Bundle One in the Deadline GUI via the Shared-job settings tab (currently we are just checking 'name' for now).
• Navigate to Specific-job settings tab, then Verify/Hit 'Load a different job bundle' button. Then, select a second existing job bundle (named 'Job Bundle Two').
• Verify Job Bundle Two in the Deadline GUI via the Shared-job settings tab (again, we are just checking 'name' for now).

Note that additional tests/checks will be added to verify more details on the Shared-job settings tab, in addition to new tests being added to verify the Specific-job settings tab and Job attachments tab once this initial PR is merged (as I also didn't want to submit a longer PR).

Custom Job Bundles:

Two new custom job bundles were written/created from scratch for specifically this test suite (and generally should not be used anywhere else except this test suite). A few notes on these job bundles is that they are very basic and do not reflect any real render jobs as the focus is on verifying correct UI and defaults. Both job bundles together more or less test all the different UI elements that can be generated via OpenJD job templates and both include a single Step. Both custom job bundles have also been tested/validated as well with the following OpenJD cli commands:

openjd --check: This was run to ensure that the template.yaml file passed all validation checks (ensuring proper formatting/syntax, etc. All checks passed.)
openjd --run GUISubmitterTesting: This was run to ensure that the Step processed as expected with no issues (and they did).

More details on the custom job bundles...

They are named Job Bundle One and Job Bundle Two (I am open to any more creative names if possible). They live in a folder called deadline_gui_test_samples, alongside the suite_deadline_gui test suite folder. Additional test artifacts created for the Squish tests can be added into deadline_gui_test_samples in the future if necessary. While these custom job bundles focus on verifying UI and not real rendering, they DO contain "mock" rendering settings that one might see in a DCC app such as Nuke, etc. I am open to more suggestions on how to make the mock UI/render settings more creative/relevant as necessary).

• Job Bundle One: Consists of a test file (which is just a simple .txt) and some test directories, which will be used to test the job attachments tab.
  
  
  

• Job Bundle Two: Only consists of a template.yaml file without any additional test files/directories for testing job attachments (as we are already doing that in Job Bundle One).
  
  

What was the solution? (How)

See details in previous section as just about all the details were written there. Test cases were identified and two new custom job bundles were written so that the test cases could be automated using Squish framework.

Other Super Minor Note: Additional cleanup were made to existing files for better clarity and accuracy in naming, especially as we build out these tests. For example, there was a file originally named gui_helpers.py but that was renamed to workstation_config_helpers as that is clearer, and gui could mean anything. Additional naming fixes will also come in the future (but this is a minor note). Note that two new files were added that are called gui_submitter_helpers and gui_submitter_locators (which refers to the GUI Submitter dialogue). This should not be confused with gui_helpers and gui_locators (which originally referred to the Deadline Workstation Config/Settings dialogue). As these files were renamed, you will see changes in various files such as tst_verify_settings_dialogue that only had to do with replacing the names (and no actual code change).

What is the impact of this change?

Increased test coverage of our code base especially in regards to loading existing Job Bundles in the Deadline GUI Submitter, which is key functionality for the Deadline CLI/GUI.

How was this change tested?

I ran all test suites together (tst_verify_settings_dialogue and tst_gui_submitter_bundles) and ensured that they passed as expected with no issues.

The following screenshot shows logs for the tests passing for the tst_gui_submitter_bundles test suite):

Additionally, see previous details above on the tests/checks I ran for the two custom job bundles using the OpenJD CLI.

See DEVELOPMENT.md for information on running tests.

• Have you run the unit tests? N/A
• Have you run the integration tests? N/A
• Have you made changes to the download or asset_sync modules? If so, then it is highly recommended
  that you ensure that the docker-based unit tests pass. N/A

Was this change documented?

There is internal documentation for internal usage. As these tests cannot yet be run publicly in the Github repo, a public ReadMe is not yet necessary (though I am happy to write one if requested).

• Are relevant docstrings in the code base updated? N/A
• Has the README.md been updated? If you modified CLI arguments, for instance. N/A

Does this PR introduce new dependencies? No.

This library is designed to be integrated into third-party applications that have bespoke and customized deployment environments. Adding dependencies will increase the chance of library version conflicts and incompatabilities. Please evaluate the addition of new dependencies. See the Dependencies section of DEVELOPMENT.md for more details.

• This PR adds one or more new dependency Python packages. I acknowledge I have reviewed the considerations for adding dependencies in DEVELOPMENT.md.
• This PR does not add any new dependencies.

Is this a breaking change? No.

A breaking change is one that modifies a public contract in a way that is not backwards compatible. See the
Public Contracts section
of the DEVELOPMENT.md for more information on the public contracts.

If so, then please describe the changes that users of this package must make to update their scripts, or Python applications.

Does this change impact security? No.

• Does the change need to be threat modeled? For example, does it create or modify files/directories that must only be readable by the process owner?
  • If so, then please label this pull request with the "security" label. We'll work with you to analyze the threats.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[amarsjac]

Should the embedded script have a set -euo?

[rena-cheng]

I don't it's necessary given how simple my script is ('echo' is a very simple command (and almost never fails).

Maybe the only reason to add it is to add consistency across all the Deadline Cloud Job Bundles that have been written, but I noticed some do NOT have set -euo added, including GUI Control Showcase which I've referenced: https://github.com/aws-deadline/deadline-cloud-samples/blob/mainline/job_bundles/gui_control_showcase/template.yaml

So I think for now I will exclude it!

[amarsjac]

Same as previous question.

[rena-cheng]

Responded above.