Is possible to enable verbose mode to see all requests which cross Gock?

[Stéphane Klein]

Hi,

is possible to enable verbose mode to see all requests which cross Gock?
If not, I suggest to add it, it is very useful to debug.

Best regards,
Stéphane

[Tom]

There's no verbose mode. You can partially inspect not mocked/matched HTTP requests by calling: gock.GetUnmatchedRequests(), but that only solves part of the problem here.

What I would be open to considering is first-class support for easy to use traffic observers instead of a generic debugging layer, for instance:

gock.Observe("request", func (req *http.Request, mock gock.Mock) {
  // do whatever you need with the request, such as:
  log.Printf("Incoming request: %#v", req)
})

gock.Observe("mock", func (req *http.Request, mock gock.Mock) {
  // do whatever you need with the request, such as:
  log.Printf("Mocked request: %#v", req)
})

Observers can be only used for read-only, side-effects free traffic observation, not for control flow, filtering, transformation...

That way the developer can easily implement and integrate its preferred debugging mechanism.

[Stein]

I wouldn't mind picking this up. I spend a fair bit of time debugging requests that don't match and usually point to my forked gock with this change: steinfletcher@8f86c0d

@h2non this is similar to your proposal but without the gock.Mock parameter. Can you take a look at my commit and suggest and changes, then I can create a PR.

Cheers

[Tom]

@steinfletcher Thanks. Nice job.

It looks good for an initial implementation, but I would like to be able to differ between outgoing requests and actually matched mocked requests.

Implementing an observer mechanism based on events looks solid and versatile to me.
Do you have any idea and use cases that can fit here?

Feel free to send the PR and we can iterate from that.

[Stein]

@h2non Great. So is the gock.Mock parameter the mock that matches the request and nil if there is no match, OR would the observer be invoked for each registered mock which allows the user to perform their own diff?

My use case is when a match fails I want debug why it doesn't match, I wonder if it might be a little too complex to perform a diff - especially when there are several registered mocks. It might be enough to just look at the outgoing requests and eyeball the difference.

The httputil.DumpRequest method is quite nice for printing the outgoing request. Would you want the observer implementation to always be provided by the consumer? It's quite nice to have a default implementation of the observer which I think will satisfy most users. Then users can supply their own if necessary. But I am not fussed.

Let me know what you think and I'll submit a PR :)

[Tom]

@h2non Great. So is the gock.Mock parameter the mock that matches the request and nil if there is no match, OR would the observer be invoked for each registered mock which allows the user to perform their own diff?

Yes, nil should be used if no mock is matched, but observer triggering flow should be based on outgoing intercepted HTTP traffic, not driven by registered mocks (do not trigger observers per each individual mock).

Diff mechanism should be out of the responsibility here. Users are always welcome to implement it by themselves.

My use case is when a match fails I want debug why it doesn't match, I wonder if it might be a little too complex to perform a diff - especially when there are several registered mocks. It might be enough to just look at the outgoing requests and eyeball the difference.

Yes, I think so. The underlying goal here is to provide a more simple inspect/debug mechanism, but also giving flexibility to users if they want to implement fine-grained inspection.

The httputil.DumpRequest method is quite nice for printing the outgoing request. Would you want the observer implementation to always be provided by the consumer? It's quite nice to have a default implementation of the observer which I think will satisfy most users. Then users can supply their own if necessary. But I am not fussed.

That's fine. We can implement as you suggest in the default built-in debugger/observer function.

Let me know what you think and I'll submit a PR :)
Please, feel free to submit the PR and let's iterate from that 👍

[Stein]

Thanks for your input @h2non, I'll get back to you in the near future with a PR

[Stein]

I found a new use case for this feature. At Sainsburys we use gock for our behavioural/black box api tests. So this enables us to intercept the requests and auto generate sequence diagrams from the test: Example here: https://htmlpreview.github.io/?https://github.com/steinfletcher/gock/blob/feature/diagram/sequence-diagram.html