How to write UI Test using codeless

1.Creating UI Test Suite

• Setup a root folder named suites in example_usage which contains all the .xlsx test suite files (API, UI or a hybrid), including new ones you would write yourself.
• Create a new .xlsx file in example_usage
  ExampleFileName: "demo_ui.xlsx".
  ExampleTestSuiteFilePath: project_directory/codeless_skeleton/suites/demo_ui.xlsx.

1.1 Setting up UI config sheet

• Create a config sheet in the .xlsx file that was created in the step 1. Config sheets MUST use the preface "c-" .
  Example UI config sheet name : "c-demo".

key	value	comments
platform-type	chrome	Web driver platform type. Valid values are chrome, firefox, ie or emulator. Please note that ie is ONLY a valid option if running from a Windows OS.
webdriver.runlocal	TRUE	Runs the webdriver on the local machine if TRUE, if FALSE runs on the remotw webdriver.
webdriver.path.chrome	web_drivers/windows/chromedriver.exe	Path to the chrome webdriver to use for this machine. Installed under codeless skeleton <INSTALL_DIR>/lib/webdrivers// by default. For Windows: lib/web_drivers/windows/chromedriver.exe For Mac: lib/web_drivers/mac/chromedriver.exe
webdriver.platform.chrome	Windows	Platform type for remote web driver intializing.
webdriver.version.chrome	61.0	Version for platform type selected.
webdriver.path.firefox	web_drivers/windows/geckodriver.exe	Path to the gecko webdriver to use for this machine. Installed under codeless skeleton <INSTALL_DIR>/lib/webdrivers// by default. For Windows: lib/web_drivers/windows/geckodriver.exe For Mac: lib/web_drivers/mac/geckodriver.exe
webdriver.platform.firefox	Windows	Platform type for remote web driver intializing.
webdriver.version.firefox	60	Version for platform type selected.
webdriver.path.ie	web_drivers/windows/IEDriverServer.exe	Path to the IE webdriver to use for this machine. Installed under codeless skeleton <INSTALL_DIR>/lib/webdrivers// by default. For Windows only: lib/web_drivers/windows/IEDriverServer.exe no other valid settings.
webdriver.platform.ie	Windows	Platform type for remote web driver intializing.
webdriver.version.ie	11	Version for platform type selected.
webdriver.hub	remote webdriver url	Ex: Sauce url to run it on Sauce labs

1.2 Writing a sample UI TestCase:

• In this sheet, the user can start writing out the test steps desired for this test case, using the Framework Suite Keywords.
• Create a new sheet in the same suite file that was created in step 1. TestCase sheets MUST use the preface "t-"
  Example UI TestCase sheet name : "t-test1".
• Test suites must have at least one TestCase sheet, but can have as many as needed.

This sheet defines five common columns that are used by the framework to load it appropriately.

An example of a TestCase sheet can be found in the example_usage/suites directory.

• Step column
  • Required.
  • Short description of the test step. Can be any text value.
• Action column
  • Required.
  • Codeless Framework keyword.
  • Defines action the Codeless Framework will take for this test case step.
• Target column
  • Required for click, sendKeys and serviceCall actions.
• Input column
  • Required for config, navigate, sendKeys and serviceCall actions.
  • Variable text field depending on action selected.
• Override column
  • Optional in most cases. Required in some cases with API service calls. (serviceCall action).
  • Variable text field depending on action selected.

Example UI test sheet name : "t-test1".

Step	Action	Target	Input	Overrides
config setup	config
Navigate to UI page	goto		https://google.com
search for "T-Mobile"	sendkeys	{{searchElement}}	T-Mobile
click search	click	{{searchBar}}
close browser	close

Commenting out test steps:

Users can skip test steps if the step name is prefixed with '#' symbol. example:

#step_name

1.3 Writing a sample UI Datasheet

• In this sheet, the user can create keys with values that is used in the test sheet to overwrite variables such as the host or web element.

Suite Keywords.

• Create a new sheet in the same suite file that was created in step 1. Datasheet MUST use the preface "d-"

Example UI Datasheet name : "d-datasheet".

Key	Value
searchElement	Google.googlepage.searchbar
searchBar	Google.googlepage.searchbutton
TMobile	https://www.t-mobile.com

1.4 Writing a UI Assertions

You can define assertions under override column of you test steps. Below shows assertion examples and description of them.

Different kinds of assertion types

Override	Description
assertNotNull::WebElement	Checks if an element you have targeted exists or not
assertEquals::WebDriver::getTitle::expected	This compares title of the navigated page equal to expected string value
assertEquals::WebElement::getText::expected	This assertion is similar to the 2nd one, the difference is on top we are geting title of the page from webDriver here we are getting text value of an element and comparing it with an expected string value
assertEquals::WebElement::getTagName::input	This is an assertion used if you like to check whether an element is an input field by checking tag name of the element. you can check different types of tag names.
assertEquals::WebElement::getText::expected::NumFormat(%,d)	This is an assertion used if you like to compare the text of an element with the value of an expected string that is being formatted to be a number with commas placed every 3 digits. For more information on more number formats, please refer to https://docs.oracle.com/javase/tutorial/java/data/numberformat.html