Howto solve this steps order problem

[stephanedaviet]

I have defined the following test:

## Caching a cacheable response

* A "GET" request is sent to the server
* A response with status "200" and headers "Cache-Control: max-age=60" is received
* The response is stored in the cache

I have the following implementation:

@Step("A <method> request is sent to the server")
public void aRequestToAResource(HttpMethod httpMethod) throws Exception {
    when(mockedRequestLike.method()).thenReturn(HttpMethod.GET);
    when(innerMockedHttpClient.sendRequest(any(RequestLike.class)))
            .thenReturn(mockedResponseLike);
    httpClientWithCache.sendRequest(mockedRequestLike);
}

@Step("A response with status <httpStatus> and headers <httpHeaders> is received")
public void theResponseHasStatus200AndHeaderCacheControlMaxAge60(int httpStatus,
                                                                 String httpHeaders) {
    when(mockedResponseLike.status())
            .thenReturn(HttpStatus.resolve(httpStatus));
    when(mockedResponseLike.headers())
            .thenReturn(HttpHeaders.fromString(httpHeaders));
}

@Step("The response is stored in the cache")
public void theResponseIsStoredInTheCache() {
    verify(innerMockedCacheStore).put(mockedRequestLike, mockedResponseLike);
}

The problem is that the implementation of the httpClientWithCache.sendRequest(...) deals with some states of the response. Those states are mocked in the steps that follow the sending of the request, too late for the sendRequest algorithm logic.

What's the best way to set up the response mock before sending the request, while keeping an idiomatic and logical way to define the test steps? I logically don't want to define the state of the response before sending the request in my specification…

[sriv]

Do you have a reference on how you would do this in say a JUnit test? I am trying to understand the flow better. In my head, mocks typically need to be set before passing it to the test subject. A retrospective mock may not be visible, so I don't know if this is a problem with gauge steps or the way the mocks are setup.

[stephanedaviet]

Yeah, I see what you mean. I have written numerous unit tests in the past in JUnit. The fact is that in JUnit, I would write only one method for the whole test with the freedom to mock the response at the start of the method while doing actually the request sending after that mocking. Here, because each step matches one independent method and those are executed sequentially , I'm a little stuck.

I could always mock the response in a previous step, but it doesn't seem the proper way to do that: the content of the step metho should match the intent of the corresponding specification. I'm seeking for a smarter way to do that.

[chadlwilson]

IMHO mocking is more of a given/when/then style of traditional gherkin/bdd style testing and is typically not something I'd try and do with something like gauge, because your step definitions and ordering are likely to broadly end up mirroring the mocks, if you make them as fine grained as your example.

There's nothing to stop you expressing steps this way with Gauge so you set up expectations prior to sending but it's unlikely to feel idiomatic to gauge, and you'd probably need to be storing the mock in the state and retrieving it in later steps to perform verifications coupled with earlier mock setup.

[chadlwilson]

It'd probably end up more like

## Caching a cacheable response

* Given I have a server which responds with 200 to "GET" requests with headers "Cache-Control: max-age=60"
// ^^ set up mocks
* The GET request is sent to the server
* The expected response is stored in the cache

To me, I'm not sure if Gauge adds sufficient abstraction to make it helpful.

[stephanedaviet]

Yeah, during the night, I came mostly to the same conclusion: express the state of the response as the expected behavior of the server. Thanks for your response and this helpful advice!