[Iris 2.0] Extensibility

Title:

Extensibility

Author(s):

Matt Wobensmith

Tracking issue:

Short description:

This is the mechanism that allows third parties to add support for their test target to Iris 2.0.

Use case(s):

A developer working on a desktop application wants to create a visual test suite for UI and functional testing of their product. They decide on Iris because it's free, open-source, easy to use, and supports easy extensibility via a well-known Python test framework - pytest.

Getting started is simple, as there are base classes for the pytest plugin as well as test cases. Also, the SDK tells them what assets they can add to make their target module presentable in the overall Iris user interface.

Once the developer has finished their Iris target, an end user will get the Iris project and configure their system using the documentation. In addition, when they run the Iris bootstrap script, it will find any target-specific bootstrap scripts and invoke them as well. Assuming that the developer has authored their target module correctly, the user will launch Iris and see their target represented in the Control Center, ready for use.

Implementation:

• Overview

The targets folder contains all test targets supported in Iris. Firefox is one of them, by default. Whenever Iris is invoked, it scans the targets folder for viable test targets and queries their assets, in an attempt to a) verify them and b) collect their metadata in order to present it in the Control Center, to allow the user to interact with it.

TBD: tests, arg subparsers

• Sample code

Each target must have the following items:

• An app.py module with a class that imports all from src/base/target.py, and inherits from BaseTarget.
  • The class - which is now a valid pytest plugin - should define some properties in its constructor to be used by Iris:
    

self.target_name = 'YOUR_TARGET_NAME' [1]
self.cc_settings = [] [2]

[1] This is mandatory, in order to display your target name in the Control Center pages.
[2] This is optional, but will allow your target to request UI in the Control Center for users to configure parameters when running your target code.

• There must be a file called icon.png, which is an image sized XX by XX pixels. It will be used in the Control Center. An image with a transparent layer works best.

• Optional: if your target requires system dependencies that are not installed by the Iris bootstrap script, then place your own (platform-specific) scripts inside a subdirectory named bootstrap, inside your target's folder.

• Lastly, any tests that your target uses will go in the repo's root tests folder, in a subfolder named for your target. This folder's name must match your target folder's name.

• New and/or changed files and directories

TBD

• Control Center

This feature has a specific API to be used to affect data in the Control Center, such as target icon/name, tests, as well as any desired controls to be used to configure a test run.

• Localization

This should not impact localization.

• Documentation

This will require an SDK document.

• Bootstrap

If a bootstrap folder is present within the target folder, the main bootstrap script will prompt the user to run it. A target's bootstrap script is responsible for detecting platform/OS details when determining what to install.

• Setup

TBD

Risks:

• Dependencies on other people/teams/software.

Is this feature ready to be implemented or are we waiting for others? Are there any outstanding (or potential) issues in dependent software that we need to be aware of?

• Other factors that could influence functionality or schedule.

Do you anticipate any changes that could impact your design?

Estimated schedule:

• xxxx-xx-xx Spec due date (this)
• xxxx-xx-xx Implementation
• xxxx-xx-xx Code review
• xxxx-xx-xx Testing
• xxxx-xx-xx Final check-in date