Access the response status and headers of the Client Response about microshed-testing HOT 7 CLOSED

I like the idea of giving users more low-level validation access to their HTTP endpoints. Currently users can do this if the REST client returns a javax.ws.rs.core.Response object, but in many cases REST clients do not because it's more convenient to simply return a POJO from the JAX-RS method.

One popular REST testing library I know if is REST-assured. Here is a good article about it: https://www.baeldung.com/rest-assured-tutorial
If you look at section (7) it talks about configuring the library, perhaps we could automatically detect the presence of the RestAssured class and if it's present then microshed would automatically bootstrap it (e.g. set baseURI, base path, port, etc). This would allow us to have a test case that looks like this:

@MicroShedTest
public class MyTest {
  @Container
  public static ApplicationContainer app = // usual config

  @Test
  public void testCreatePerson() {
    // validate that POST request to
    // http://<container-ip>:<container-port>/myservice/?name=Hank?age=52
    // returns HTTP 200 with content type JSON
    given()
        .contentType(JSON)
        .queryParam("name", "Hank")
        .queryParam("age", 52)
      .when()
        .post("/")
      .then()
        .statusCode(200)
        .contentType(JSON);
  }
}

from microshed-testing.

This looks quite good 👍

from microshed-testing.

created a draft PR for the integration here: #134

It can't be merged until the corresponding PR I made on REST-assured gets merged though

from microshed-testing.

wow, that was fast 👍 I'll try it over the weekend while building REST-Assured with your PR locally

from microshed-testing.

works great and I really like the given/when/then structure of Rest Assured.

Just out of curiosity, if now a user wants to plug a custom MessageBodyReader or MessageBodyWriter e.g JAXB or for whatever reason, he/she uses binary formats like Kryo, this would always result in effort and adjustment within RestAssured, or? I assume 80% of the use cases are fine with JSON but the rest might need something different

from microshed-testing.

RestAssured has builtin converters for JSON and XML formats, but if a user wants to implement a converter to handle a custom data format.

For JSON-B integration with RestAssured I could have just written the converter in MicroShed code, but then we'd need to have a dependency on RestAssured which I wanted to avoid (i.e. not even an optional dependency)

from microshed-testing.

PR #134 adds the integration with REST Assured and is now merged, it will be available in the next release (probably 0.6.3)

from microshed-testing.