When should I use components in my script?

Components are a great way to break up a complex script, to add variety to a script’s execution, to loop through complex steps, and to organize business processes. This article provides some common scenarios that can be handled via components.

Adding a Component

Follow these steps to add a component to your script.

  1. Double-click on Define Component under Application actions. A new tab is added to the script. It defaults to “NoName”.
  2. In the Name property, give your component a name.
  3. If the component will require variables, you can configure variables separately from the main script.
  4. Add steps to your component.

Calling a Component in a Script

Once you’ve created a component, you must call it from somewhere or it will never be executed. Follow these steps to execute the component from your script.

  1. Drag Execute Component onto the script.
  2. Under Properties, open the Component Name drop-down and select the component to execute.
  3. If you need to act on the success or failure of the component, add a meaningful name to the Execution Status Variable property.

Scenario 1 – Common Steps Executed Throughout the Script

After creating a long script, look through it and see if there are any repetitive steps that occur throughout the script. If so, these steps are good candidates to move to a component. To do this, create a new component, select the repetitive steps and copy them to the component. In the main script, delete the repetitive steps and then add an Execute Component step to call and execute the newly created component.

Breaking up a long script into components can make it much easier to understand and manage.

Scenario 2 – Decision Making

I’m emulating a user process where the user reaches a decision point that can take them down different paths. Rather than add the complexity to the main script, this is a great place to add components. Follow these steps to set this up.

  1. Create a component for each possible branch the user could take. NOTE – if the process is very complex or has repetitive steps, you can have components that call other components.
  2. Create a variable to hold the branch to be taken. This can be a defined variable, or a column in an Excel or CSV file.
  3. Add a switch/case statement to the main script with a case that has the Execute Component action. Set the switch to the variable created in step 2.
  4. Add a case for every component you could call.

When your script reaches the switch step it will perform the steps in the component that match the case value in the variable.

Scenario 3 - Multiple Tabs in the Application

Sometimes adding or editing data in an application means interacting with several tabs in a window. This is a perfect opportunity to split up the script into components. Create a component for each tab with all the steps that need to be completed on that tab.

Scenario 4 – Functional Testing Validation Steps

If you are using AppVerify and it is having issues finding the verify image; or if you need to not only find an image, but perform some additional steps for the verification, then add the verification steps to a component. The component can then be called as the verify step in AppVerify.

Scenario 5 – Multiple CSV files

Another good time to use a component in your script is when you need to use different CSV files for different parts of the scenario. Each component can have a separate CSV file from the parent script. Here’s an example. I am testing an application that dispatches service workers out to fix broken appliances. The process I’m testing has three main parts: the customer with the broken appliance, the broken appliance, and the technician that is going to be dispatched. The appliances that the company repairs changes on a regular basis as well as the technicians. If I had all the data needed to populate the script in one CSV file, it would be time consuming to update. A better method would be to have a main script that handles the customer info from a CSV file and then add two component scripts; one for the appliance info entry and one for the technician entry. Each component would have its own CSV file. Then when a new appliance is added, or a technician removed there is one change to make in the CSV file.