TestCase File

The TestCase file is a fundamental component of the DASKALOS TestRunner framework, designed to store and structure your automated test scenarios in a straightforward, easily editable format. Written in CSV format, the TestCase file ensures flexibility and simplicity while maintaining the ability to scale for complex automation needs. The first line of each TestCase file specifies the version number, followed by a description of the file format. Lines that begin with “#” are reserved for comments, allowing for clear documentation and notes within the file. The standard format includes essential fields such as the project name, test case name, and the specific test steps, which follow a defined structure to ensure consistency. Version 1 of the TestCase format includes: Description, Object Name, Object Option, Action, On Fail, and Data. This approach ensures that test cases are easy to create, maintain, and extend as your automation needs evolve.

#!FormatVersion=1
#
# File Format
# Description,Object,Object Option,Action,On Fail,Data
#
# Project Name: swaglabs
#
# Test Name: tc01
#
Verify Home page,notused,,VerifyPageTitle,continue,[swaglabs.pagetitle.homepage]
Enter username,swaglabs.login.username,,set,continue,[swaglabs.login.lockedoutuser]
Enter user password,swaglabs.login.userpassword,,set,continue,[swaglabs.login.userpassword]
Click on the login button,swaglabs.login.loginbutton,,click,continue,
Verify Page,notused,,VerifyPageTitle,continue,[swaglabs.pagetitle.homepage]
Verify error message is displayed,swaglabs.login.errormessage,,VerifyText,continue,[swaglabs.login.errormessage]

 

In-Depth Breakdown of the TestCase File Format

Description of the First Line: #!FormatVersion=x

The first line in the TestCase file is crucial for instructing the DASKALOS TestRunner on how to read and interpret the file. This line follows the format #!FormatVersion=x, where x represents the version number of the TestCase file format.

The FormatVersion is required and plays an essential role in ensuring compatibility with different versions of the test runner. By specifying the version, the TestRunner can adjust its parsing logic based on the format version, allowing for the introduction of new file formats or changes to the structure in future versions without impacting existing TestCase files. This flexibility ensures backward compatibility, meaning older TestCase files can still be executed seamlessly even when new features or formats are introduced.

Header Section

The header section of the TestCase file is optional and serves purely for documentation purposes, making the file easier to read and understand by the end user. Any comments within the header begin with the # symbol, and while this section has no impact on the actual execution of the test, it provides valuable context for those maintaining or reviewing the file. A well-organized header can include details such as the file format layout, project name, and test case name. Additionally, users can include metadata like the author’s name, creation date, and revision history to track changes over time. Including this information helps ensure clarity and consistency, particularly when the TestCase files are shared or managed across teams.

Test Step Format

Each test case is composed of individual test steps, which follow a structured, keyword-driven format to define the actions to be performed. The format consists of the following fields: Description, Object, Object Option, Action, On Fail, and Data.

  • Description: This field provides a human-readable explanation of the step to be performed. It serves to make the test case more understandable and is also useful in reporting to provide clarity on what each step is intended to do.
  • Object: This refers to the name of the object that will be interacted with during the test. If no object is involved, this field is left blank.
  • Object Option: Used for dynamic or variable objects, this field contains additional details to identify the object more specifically. This is particularly useful when elements on the page are generated dynamically, such as in cases where IDs or classes change with each test run.
  • Action: The specific action to be performed on the object, such as “click”, “setText”, or “verify”. This field defines the actual interaction that will occur.
  • On Fail: This field specifies the action to take if the step fails. Options typically include “continue” (move on to the next step) or “abort” (stop execution of the test).
  • Data: Some actions, like entering text into a form field or selecting an item from a dropdown, require additional data. This field provides that data, which can be static or dynamic, depending on the test case.

By following this structured format, test steps are clearly defined and easy to maintain, ensuring readability and consistency throughout the testing process.

Special Formatting with Brackets

In the DASKALOS TestRunner framework, certain values within the test case file are surrounded by square brackets [ ]. This special formatting indicates that the data enclosed within the brackets is dynamic and needs to be resolved during runtime. The values inside the brackets can be sourced from various places, such as a pre-defined data file, parameters provided at the start of the test case, or values defined within the test configuration file.

This dynamic approach allows test cases to be more flexible and reusable, as the same test case can be run with different data sets without the need to modify the test steps themselves. For example, a value within brackets could represent a user name, password, or a test-specific URL, and can be defined in the configuration or data files to vary depending on the test run. This enables more efficient testing, as you can execute the same test with different inputs, making it easier to cover a wide range of scenarios.