Test resources

Introduction

Test Resources are the objects that supplement a Test Case

The objects can be:

• Applications: Applications are the platforms under test (Web, Mobile, Desktop App)
• Keywords: Keywords are objects that group operations for later use
• Data Driven: Data Driven are files that store input data
• Databases: Databases are connection to databases to validate/test databases
• Web Services: Web Services are the API (SOAP/REST) scripts to test
• Variables: Variables are objects that contain values created during an execution

Applications

Applications are the platforms you will automate, it is what Test Path call the "Primary" technologies to test

Applications can be:

• Web
• Desktop App
• Android
• iOS

For a Test Case to call an Application, simply add the Launch (Attach operation also works in case of Desktop App) operation in your test, and choose the application to connect

After creating an Application, you can use the Spy feature to map objects to automate in your Test Cases

Your Application objects are the objects that you will use in the Test Case for automation, several ways to map them exists

• Using the Spy feature in the Application Page
• Using the Debug feature in the Test Case
• Manually adding objects (Web and Mobile Only) choosing either Xpath or Text for mapping
  • for Text Mapping, the Text can be a button Text, a field title, a textbox placeholder or even a field's label
  • the system will try to create the object with the Text and map out the remaining properties

Cognitive Repair

Cognitive Repair is available for Web, Mobile Applications (Web bases) and Desktop App objects (Image mapped)

During executions, tests will try to "self repair", if an object was repaired, it will be displayed in Cognitive Repair

Opening Cognitive Repair, the user will be able to compare the mapped object witht the repaired object, and if he accepts the repaired version, can finalize the repair

Environments

An Application can have more than one Environment (for instance, in a Web Application you can have the DEV,QUAL,PROD,etc with different URLs)

You can create these environments in the Environment List

You create the Environment and select the new value (URL for Web, Path for Desktop and Mobile)

To set a test to work with the Environment, in the Test Case, in the Launch operation, fill the "Array Index" or "Environment" value with Environment Code

Remote Devices

Remote Devices can be created to connect to a remote farm

• BrowserStack
• SauceLabs

Keywords

Keywords are objects that are used to groups a set of operations for later use

These Keywords can be created in The Keyword Page, or from the Test Case

The goal is for the Keywords to be as lclose to a Test Script as possible

So, jsut like the Test Case. some options are the same (Save, Time Machine)

A Test can call as many Keywords as you wish, and a Keyword can also call other Keywords

Arguments

Keyword arguments can meke the keywords work in a dynamic way, that way the Test Cases can choose the input data for a Keyword (example: Keyword for a Login Process)

To create an argument, place the argument key in either the Object or Data field

more than one field can have the same argument, this simly means the value will be reused in those fields

• The argument is created with the argument number betweeen &( and )& (Example: for arguemnt 1, &(1)& will generate the argument)

After manuall creating your agument(s), you can click "Generate Arguments" to add them in the argument list (you can also add the argument from the list, the button does automatically)

In the argment list, the name of the argument can be changed, this name will appear in the script, and in the Test Case it will be displayed in the placeholder

Data Driven

Data Driven can be created to store input data that is meant to be reusable

Data Driven can be General or connected to a specific test

THe goal of Data Driven is to be similar with Excel files, an Excel file can be used to fill a Data Driven

• Note: The first row of the Excel file is reserved for the column names

Data Driven can have unlimited rows and columns (coumns must have different names)

For Data Protection, a Team Leader can hide values from users

Databases

Database Connections can be added for testing purposes

Database in TestPath supports:

• SQL Server
• MySQL
• ORACLE
• MongoDB

After setting up a database connection, it will be possible to create a Spy session to test your scripts

MongoDB Settings

For mongoDB queries, there is a formula to retrieve the values:

MongoDB Calls supoprt 3 arguments

• Collection: Name of the collection (mandatory)
• Filters: search filters (optional), multiple filters supported (Filter1=Val) (Filter1=val,Filter2=val2,etc)
• Projections: the fields to show (optional), multiple projections supported (Projection1=Val) (Projection1=val,Projection2=val2,etc)

The format for MongoDB calls is: Collection;Filters;Projections

MongoDB results are saved in a table with columns Index (Row counter) and Result (JSON with the result)

ReadCell and ReadJson operations can be used to read specific values for validations

Web Services

The types of web services supported are:

• REST
• SOAP
• SOAPUI Integration

The user can select the return type of a web service call

• Raw Text
• JSON
• XML

WebServices are avaiable in the Spy feature, allowing the user to tests their calls

REST

To create and execute REST Web Services, create a WebService and choose REST as a technology

in the button + New REST Call, the user can create new REST Calls, by filling the fields:

• Name: the name of the call, which will be used in the tests (can't be duplicated)
• Method: the type of call (GET,POST,PATCH,etc)
• URL: the URL of the call
• BODY: the body of the call (xml, json). this field is optional
• Headers: the REST Headers necessary to make that call. this fields are optional

REST Calls are supported by variables, they can be placed in the URL, BODY and Header fields.

SOAP

To create and execute SOAP Web Services, create a WebService and choose SOAP as a technology

the WSDL can be added in the text field, and saved using the + Update WSDL button

To generate the new Calls, save the WSDL following the instructions above, and execute the Spy feature, a button called "Generate SOAP Structure" will be available, by clicking it, all the calls inside the WSDL will be added to the WebService, and the Body auto-filled with a template

new calls can't be made, but the user can modify and copy existing calls

• Name: the name of the call, which will be used in the tests (can't be duplicated)
• SOAP Action: the SOAP Action that will execute (not recommended to change)
• SOAP Service: the URL of the SOAP Call (not recommended to change)
• BODY: the body of the call (xml). this field is optional

SOAP Calls are supported by variables, they can be placed in the BODY field.

SOAPUI Integration

To add a SoapUI Project, the user uploads a .xml SoapUI Project, it will display a list of TestSuites and TestCases of the Project

SOAPUI Integration supports the following operations:

• Upload:Uploads a SoapUI Project

To execute a WebService Test, in the test case, select the operation RunWebServiceTest, the data will be TestCase;Property1=X;Property2=Y;... (properties are optional)

The Global properties have to be defined in SoapUI, using the Global Properties Menu, adn in the test steps on soapui, the parameter will be ${PropertyName}

Variables

Variables are objects that are created during executions, they can be used to store values and use them later in a test, or in different tests, since they can be setup to be global for the entire project

To use a variable, insert the name of the variable between %( and )%, example %(VARNAME)%

To set a variable as Global, you can toggle in the Variable options menu