Search code examples
karateintuit-partner-platform

Reuse of feature files with retry until


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)

Solution

  • 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.