API - Execution Context

[matejicko]

For end-user it is necessary to work with the attributes of current Request and its Response. Currently executed request and its response is stored in these attributes:

var req = tp.Request;
req.Headers.Add("Application-Type", "25");

...

var res = tp.Response;
var body = res.Body.ToJson();
tp.SetVariable("EntityId", body.Id);

Since, usually tests are run within collection, user should be able to access to older request/responses by its name. Naturally, this has one condition - the request/response has to be named in order to find it. Retrieval of these information wil be pretty straightforward:

var oldResponse = tp.Responses["My First Request"];
var oldBody = oldResponse.Body.ToJson();
if (oldBody.TotalSum > 100){
    tp.Request.Body.ToJson().Add("DoNotRecalculate", true);
}else{
    tp.Request.Body.ToJson().Add("DoNotRecalculate", false);
}

var oldRequest = tp.Requests["My First Request"];
foreach(var header in oldRequest.Headers){
    tp.Request.Headers.Add(header.Key, header.Value);
}

[matejicko]

Execution Context of Multiple Requests

In many situations it can be convenient to have multiple requests within one test case - e.g. if some extra steps have to be performed before and/or after execution of main functionality. For such scenarios there are two exposed dictionaries Requests and Responses available for user in the scripts.

To identify each request, user have to name it - this can be done by decorating .http request with # @name RequestName metadata line.

Then, the work with older request (and their responses) is pretty straightforward:
.http file

# @name NewBook
POST {{apiBaseUrl}}/books
Content-Type : application/json

{
    "title": "Animal Farm",
    "author": "George Orwell",
    "numberOfPages": 212
}

### Verify creation of book
# @name GetBook
GET {{apiBaseUrl}}/books/{{NewBook.response.body.$.id}}

.csx file

var newBookReq = tp.Requests["NewBook"];
var getBookRes = tp.Responses["GetBook"];

var newBookBody = await newBookReq.Content.ReadAsStringAsync();
var getBookBody = await getBookRes.Content.ReadAsStringAsync();

tp.Test("Bodies of POST and GET requests should match",
    () => newBookBody.Should().BeEquivalentTo(getBookBody));

[matejicko]

Execution context exposure was implemented in #32. Since there were some comments, additional changes were performed within #34.

[matejicko]

Request and Response Objects

The initial proposal lacked with real structure of Request and Response - it was written just as an example without any prior researches on request and response objects in C# .NET. In the implemented reality Request is of HttpRequestMessage type and Response is HttpResponseMessage. Therefore, these don't contain Body property, but Content, which has to be read by method ReadAsStringAsync() first. Same works for Requests and Responses collections, which consists of these types of objects.

💡 This evoke the question, if the end-user should be able to access whole HttpRequestMessage and HttpResponseMessage objects, or there should be some proxy which exposes only commonly used properties? Or maybe even these objects should be decorated with more functionalities and shortcuts, which are can be convenient for end-users.

What do you say @Burgyn?