Repeaters

Repeaters allow to execute many times an HTTP request. There are scenarios where this is interesting:

• To obtain many different responses from the same endpoint.
• To download many files from a website.
• To make quality assurance, executing repetitions for each test case.
• To run load testing.
• Others.

Repetition modes

Simple

In this type, the request is invariant - always the same for every execution.

Sequential

Sequential repetitions require input data (read more below), where each input line will correspond to a request. There is no parallelism in sequential mode - a request is sent only after the previous is finished, as in a queue.

Random

In random mode, each request shall use a random line from the input data. There is the possibility of redundance, that is, the same input line may be used in more than one successive request.

Parameters

Quantity is the number of requests that will be sent.

Parallelism is the maximum degree of parallel requests at the same time.

Delay is the waiting time between the end of a request and the beginning of the next one.

INFO

In case of parallelism, the delay happens independently in each parallel "track".

Input data

Input data provides values for requests variables, allowing variations among requests.

Suppose that you want to inquiry a Fruit API and get data about oranges, strawberries and pineapples. You can do that by creating a base HTTP request, GET https://www.fruityvice.com/api/fruit/{{fruitName}}, and then create a repeater, with the following input data:

[
  { "fruitName": "orange" },
  { "fruitName": "strawberry" },
  { "fruitName": "pineapple" },
]

The video below show how to use input data in repeaters.

The input data format is a JSON array of objects, each object formed by string-string key-value pairs. Each object is considered an input line, each key-value pair is a variable (name-value).

[
  // line 1
  {
    "variable1": "ABC",
    "variable2": "123"
  },
  // line 2
  {
    "variable1": "DEF",
    "variable2": "456"
  },
  // line 3
  {
    "variable1": "GHI",
    "variable2": "789"
  },  
  {
    "variable1": "GHI",
    "variable2": 789 // invalid: needs to be string-string
  }, 
  {
    "variable1": "GHI",
    "variable2": true // invalid: needs to be string-string
  }, 
]

TIP

In repeaters, input variables have precedence over collection and environment variables.

Reports

At the end of the execution, you can extract a CSV report, containing info about result status (exception, cancelled, HTTP status code), started at, duration and which variables were used for that request.

Load testing

Repeaters can be used for load testing, either by desktop or by dotnet test and console.

Pororoca, at least for now, doesn't measure latency or throughput.

INFO

HTTP/2 and HTTP/3 operate in a different way than HTTP/1, because they multiplex many calls into a single connection, while HTTP/1 spawns new TCP connections if there are no available idle connections in the pool; this is one of the reasons that these newer versions of HTTP are faster and more efficient.

This distinction implies that the parallelism with HTTP/2 and HTTP/3 works only up to a certain point, in that requests are enqueued internally before being sent through the connection. The maximum number of concurrent requests / stream in a single connection is server-side determined. There is an interesting issue on GitHub regarding this topic.

Automation and command-line

Read more in the Automated tests page.

Delay and rate-limiting

Delay can be used for APIs with time rate-limiters.

Consider an API that tolerates only up to N calls per second. Supposing that each call takes a response time T, then the minimum delay time D is:

D >= (1/N) - T

If the response time T is 10ms and N is 5 reqs/second, the waiting time needs to be at least 190ms (1s/5 - 10ms).