Retries reporting
Some frameworks allow to retry Test
execution according to provided conditions (TestNG) or just retry it predefined number of times.
First execution is a simple TestItem
and next ones are called Retries
.
In ReportPortal these items are grouped and displayed as a sequence of executions for the same Test
:
When you click on the retries
link you can switch between Retries
and see their logs:
On the Log view
you can also switch between Retries
:
Retries reporting
Common child Test item
request (check reporting dev guide) looks like:
curl --header "Content-Type: application/json" \
--header "Authorization: Bearer 039eda00-b397-4a6b-bab1-b1a9a90376d1" \
--request POST \
--data '{"name":"example step","startTime":"1574423237000","type":"step","launchUuid":"<launch uuid>","description":"Item that should be retried"}' \
http://rp.com/api/v1/rp_project/item/<parent uuid>
With body:
{
"name": "example step",
"startTime": "1574423237000",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried"
}
And response:
{
"id": "uuid-of-the-first-step"
}
Request for a retry
looks the same, but has field retry=true
:
{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": true
}
To be displayed as a retry
reported Test item
should have the same name
, parentUuid
, launchUuid
and uniqueId
(if you provided it explicitly).
If one of mentioned fields is not matched (for example Test item
with the same name
but different uniqueId
and vise versa) Test item
s won't be grouped as retries.
Also Test item
with type Suite
cannot be reported as a retry
.
Retries handling triggered only if Test item
has retry=true
flag in the request. For example:
First request will trigger retries handling, but if it's the first reported Test item
it won't be a retry
:
{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": true
}
Second request won't trigger retries handling, because retry=false
is specified (or this field isn't provided) in the request:
{
"name": "example step",
"startTime": "1574423237100",
"type": "step",
"launchUuid": "<launch uuid>",
"description": "Item that should be retried",
"retry": false
}
As a result 2 separate Test items
will be displayed, so ORDER of sent requests matters (if send this items in reversed order they will be grouped as retries
).
In ReportPortal the only Test item
from the Retries
group that has statistics and can have an issue
attached is the one with max startTime
.
In previous requests startTime
was 1574423237000
for the first one and 1574423237100
for the second one, so the second one is a 'main' Test Item
with statistics and issue
(if attached).