Results and Reporting
Use these commands and functions to customize the results created by SenseTalk scripts in Eggplant Functional. (Also see The ScriptLogging in Global Properties.)
Assert
Command
Behavior: When you run an assert
command, Eggplant Functional evaluates the specified condition (an expression) as true or false. If it is evaluated as false then by default assert
throws an exception. It can also log a success, failure, or warning, depending on how the behavior is set. The failure behavior for the assert
command can be set in-line using the Assert
command properties as shown in the syntax and examples below. This behavior can also be set using The AssertionBehavior
Global Property. To improve readability, you can insert the word that
into an assert
command.
Parameters: A condition (expression) you want Eggplant Functional to evaluate.
Syntax:
assert {that} condition {with [warning | error | exception | pause]}
Example: Using The AssertionBehavior
Global Property to set the behavior of the assert
command upon evaluating the condition to be false.
set the AssertionBehavior to "warning" // Changes the default behavior of assertions to generate a warning instead of an exception
assert that x < 10 // Logs a warning message if the value of x is not less than 10 due to the AssertionBehavior global property set previously
Example:
assert that ConfirmationNumber is "128901823" with Exception "Validating the order confirmation number." // Customizes the assertion message
Example:
params Platform, Version, DebuggingMode
assert paramCount() is greater than 2 with error // Asserts that at least 3 parameter values were passed into the script, and if not, logs an error
Log the assertionErrorCount&&"assertions have failed." // Logs the total number of assertion errors that have occurred during the execution
Example:
Assert that ["iOS","Android","Windows","MacOS"] contains SUTPlatform // Asserts that the value stored in SUTPlatform is one of 4 acceptable values and if not, throws an exception to stop the execution.
Example:
put ReadText("ResultsUpperLeft","ResultsLowerRight") into UnfilteredResults // Uses OCR to read a number from the SUT and stores it in variable UnfilteredResults
Tap "Filter" // Performs an action on the SUT that causes a filter to be turned onWaitFor 10, "FilterOn"
put ReadText("ResultsUpperLeft","ResultsLowerRight") into FilteredResults
assert FilteredResults is less than UnfilteredResults with Warning // Asserts that the number read by OCR after applying a filter on the SUT is smaller than before applying the filter
BeginTestCase
and EndTestCase
Commands
Behavior: The BeginTestCase
command is used to open a test case, and the EndTestCase
command is used to close one. Each test case is given a name, as shown in the examples below.
Syntax:
BeginTestCase CaseName
actions
EndTestCase CaseName
Example:
BeginTestCase "SubmitLogin"
Login // Runs a script named Login. Note that calling the script with RunWithNewResults instead would automatically create a separate test case for Login
EndTestCase "SubmitLogin"
Example:
Click "SearchButton"
BeginTestCase "ResultsLoaded"
WaitFor 20, "Results"
EndTestCase "ResultsLoaded"
set myResult to the result
put myResult.testcase & comma & myResult.duration & comma & myResult.starttime & CRLF after file ResourcePath ("myTimings.csv") // Writes the duration of the test case for the "Results" image appearing out to a csv file
Example:
BeginTestCase "A" // Marks the start of the reporting period for case A
// Other commands here
EndTestCase "A" // Ends the reporting period for case A and logs the information that was gathered
BeginTestCase "B" // Starts recording information for case B
// other commands here
BeginTestCase "C" // Starts recording information for case C
// other commands here
EndTestCase "B" // Ends case B and reports information gathered since case B was opened
// Other commands here
// If the run ends with test case C still open, it will be ended and reported automatically
Tech Talk
A test case is used to block out any section of code within a script (or across scripts during a run) for purposes of gathering information about that portion of the test. A script run may include multiple test cases, which may be sequential portions of a script or may overlap with one another as desired. Information about open test cases for the current script run can be obtained at any time using the OpenTestCases
global property.
The information gathered for each test case includes:
- The duration of the test case (in seconds)
- The number of Errors logged while the test case is open
- The number of Successes logged while the test case is open
- The number of Warnings logged while the test case is open
- The number of Exceptions logged while the test case is open
- The name of the test case
- The date and time at which the test case started
One test case is created automatically at the beginning of each run, with the name of the script being run.
At the end of the run, any test cases that are still open are ended and reported automatically.
The initial handler (the script itself) is considered a test case and will be reported as one If no declared test cases are open or no test cases are declared at all, the script will be reported as the only open test case.
Test cases can overlap.
Beginning in version 5.2, Eggplant Manager automatically parses test case data from script results and displays the duration for the test cases in a dashboard chart. Parsed test case data is exportable from Eggplant Manager.
CaptureScreen
Command
Behavior: Captures a snapshot of the entire SUT screen, or a rectangle indicated in the property list. You can customize this command with a list of any number of the CaptureScreen
properties.
When CaptureScreen
is executed as part of a script, the screenshot is saved in the results folder for the script. When the CaptureScreen
command is run as part of a selection or from the Ad Hoc Do Box, the resulting screenshot is saved in your local user's document directory (e.g., C:/Users/<username>/Documents/
).
It can be helpful to know where your screenshot is being saved if you don't already know. Accessing the file path of the image captured can be done using the Result
function like this:
CaptureScreen
put the result -- Returns the full path for the screenshot that was captured on the previous line using CaptureScreen.
Images captured using CaptureScreen
in JPG format should not be used for image searching. Because JPG compression requires data loss (is not lossless), it will not reliably match using the same search settings as a PNG of the same image would.
Parameters: Parameters can be passed to CaptureScreen
in two ways. You can either pass up to three ordered properties, or an optional property list.