Having some stunning success with Karate. Working on end-to-end tests that use 'retry until' timeout on a GETs in order to wait for a specific parameter value within the response body. The parameter is expected to change state from A to B as data processing completes in the system under test. Interested to learn about patterns due to having standardised on a model of one .feature
per API route. However this is only possible if we can parameterise the retry until
terms. Otherwise this would mean writing multiple features to support different retry combinations.
---Example of reusing retry until
from comments---
To maintain a single get_notification_ref.feature
rather than one for each until
combination, provide external until
parameters in the call that can be used by the retry
within the .feature.
Implementation that relies on specifying the until parameters inside the .feature file. End up with GET Notification feature file for each retry combination :
Scenario: Get notification & wait for status
* call read('classpath:NotifyV1/get_notification_ref_wait_status.feature')
.
.
Scenario: Get notification & wait for status indicator colour
* def expectedColour = 'GREEN'
* call read('classpath:NotifyV1/get_notification_ref_wait_colour.feature')
get_notification_ref_wait_status.feature
Scenario: Get notification and wait on response status = 200
Given path 'notification', notificationTypeReference
And retry until responseStatus == 200
When method get
* def notificationResponse = $
get_notification_ref_wait_colour.feature
Scenario: Get notification and wait on response status = 200 and colour
Given path 'notification', notificationTypeReference
And retry until responseStatus == 200 && response.statusColour == expectedColour
When method get
* def notificationResponse = $
Implementation of the above that can handle parameterised retry until's would look like this - note there is now only one GET Notification feature file:
Scenario: Get notification & wait for status 200
* call read('classpath:NotifyV1/get_notification_ref.feature')
.
.
Scenario: Get notification & wait for status 200 and indicator colour
* def UntilTerm = function(response){ return karate.match(response, '{statusColour: "GREEN"}').pass }
* call read('classpath:NotifyV1/get_notification_ref.feature')
get_notification_ref.feature
Scenario: Get notification
* def untilTerm = karate.get('UntilTerm') ? UntilTerm : function(response){ return true }
* def untilStatus = karate.get('UntilStatus') ? UntilStatus : 200
Given path 'notification', notificationTypeReference
And retry until responseStatus == untilStatus && untilTerm(response)
When method get
* def notificationResponse = $
* karate.set('UntilTerm',null)
* karate.set('UntilStatus',null)
I would say retry until
may be sufficient. Since you can tweak the default time and interval, you can set this differently even at the point of need, i.e. a specific HTTP call: https://github.com/intuit/karate#retry-until
Unless you really truly have a way for the external process to call back - and in that case you can look at karate.signal()
and friends. Otherwise I think you are better off sticking to retry until
.