Unlike the C#, Java, Python, Ruby, Node.js and Go API Libraries, the PHP wrapper does not include automated file uploads. Use this for uploading results without files. If you are using PHP for build and automated test scripts and interested in a full fledged library please get in contact and we will provide you with one.
The PHP API wrapper is one file and it is not available via a package manager such as Composer, a .php file is available for download directly here: tesults.php
require 'tesults.php'
Upload your test results using the results method.
$res = results($data);
// $res is an Associative Array.
// Value for key 'success' is a Boolean.
// True if results successfully uploaded, false otherwise.
echo $res["success"] ? 'true' : 'false';
echo "\n";
// Value for key "message" is a String.
// If success is false, check message to see why upload failed.
echo $res["message"];
echo "\n";
The $data param for results is an Associative Array containing your test results in the form:
<?php
require 'tesults.php';
$data = array(
'target' => 'token',
'results' => array(
"cases" => array(
array(
"name" => "Test 1",
"desc" => "Test 1 description",
"suite" => "Suite A",
"result" => "pass"
),
array(
"name" => "Test 2",
"desc" => "Test 2 description",
"suite" => "Suite B",
"result" => "fail",
"reason" => "Assert fail in line 203 of example.php"
"_CustomField" => "Custom field value",
"params" => array(
"param1" => "value1",
"param2" => "value2"
),
"steps" => array(
array(
"name" => "Step 1",
"desc" => "Step 1 description",
"result" => "pass"
),
array(
"name" => "Step 2",
"desc" => "Step 2 description",
"result" => "fail"
"reason" => "Assert fail in line 203 of example.php"
)
)
),
array(
"name" => "Test 3",
"desc" => "Test 3 description",
"suite" => "Suite A",
"start" => round(microtime(true) * 1000) - 60000,
"end" => round(microtime(true) * 1000),
"result" => "pass"
)
)
)
);
$res = results($data);
echo $res["success"] ? 'true' : 'false';
echo "\n";
echo $res["message"];
echo "\n";
?>
The target value, 'token' above should be replaced with your Tesults target token. If you have lost your token you can regenerate one from the config menu. The cases Array should contain your test cases. You would usually add these by looping through the test case objects you currently have in your build and test scripts.
Each test case added to cases must have a name and a result. The result value must be one of 'pass', 'fail' or 'unknown'. All other fields are optional: desc, suite, params, steps, reason and custom fields (prefixed with underscore).
The 'params' value is for use by parameterized test cases and is an Associative Array containing the parameter names and values.
This is a complete list of test case properties for reporting results. The required fields must have values otherwise upload will fail with an error message about missing fields.
Property | Required | Description |
---|---|---|
name | * | Name of the test. |
result | * | Result of the test. Must be one of: pass, fail, unknown. Set to 'pass' for a test that passed, 'fail' for a failure. |
suite | Suite the test belongs to. This is a way to group tests. | |
desc | Description of the test | |
reason | Reason for the test failure. Leave this empty or do not include it if the test passed | |
params | Parameters of the test if it is a parameterized test. | |
files | Files that belong to the test case, such as logs, screenshots, metrics and performance data. | |
steps | A list of test steps that constitute the actions of a test case. | |
start | Start time of the test case in milliseconds from Unix epoch. | |
end | End time of the test case in milliseconds from Unix epoch. | |
duration | Duration of the test case running time in milliseconds. There is no need to provide this if start and end are provided, it will be calculated automatically by Tesults." : "Duration of the build time in milliseconds. There is no need to provide this if start and end are provided, it will be calculated automatically by Tesults. | |
rawResult | Report a result to use with the result interpretation feature. This can give you finer control over how to report result status values beyond the three Tesults core result values of pass, fail and unknown. | |
_custom | Report any number of custom fields. To report custom fields add a field name starting with an underscore ( _ ) followed by the field name. |
To report build information simply add another case added to the cases array with suite set to [build]. This is a complete list of build properties for reporting results. The required fields must have values otherwise upload will fail with an error message about missing fields.
Property | Required | Description |
---|---|---|
name | * | Name of the build, revision, version, or change list. |
result | * | Result of the build. Must be one of: pass, fail, unknown. Use 'pass' for build success and 'fail' for build failure. |
suite | * | Must be set to value '[build]', otherwise will be registered as a test case instead. |
desc | Description of the build or changes. | |
reason | Reason for the build failure. Leave this empty or do not include it if the build succeeded. | |
params | Build parameters or inputs if there are any. | |
files | Build files and artifacts such as logs. | |
start | Start time of the build in milliseconds from Unix epoch. | |
end | End time of the build in milliseconds from Unix epoch. | |
duration | Duration of the build time in milliseconds. There is no need to provide this if start and end are provided, it will be calculated automatically by Tesults. | |
_custom | Report any number of custom fields. To report custom fields add a field name starting with an underscore ( _ ) followed by the field name. |
If you execute multiple test runs in parallel or serially for the same build or release and results are submitted to Tesults within each run, separately, you will find that multiple test runs are generated on Tesults. This is because the default behavior on Tesults is to treat each results submission as a separate test run. This behavior can be changed from the configuration menu. Click 'Results Consolidation By Build' from the Configure Project menu to enable and disable consolidation by target. Enabling consolidation will mean that multiple test runs submitted with the same build name will be consolidated into a single test run.
If you dynamically create test cases, such as test cases with variable values, we recommend that the test suite and test case names themselves be static. Provide the variable data information in the test case description or other custom fields but try to keep the test suite and test name static. If you change your test suite or test name on every test run you will not benefit from a range of features Tesults has to offer including test case failure assignment and historical results analysis. You need not make your tests any less dynamic, variable values can still be reported within test case details.
Does your corporate/office network run behind a proxy server? Contact us and we will supply you with a custom API Library for this case. Without this results will fail to upload to Tesults.