Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
harobed opened this issue Feb 14, 2018 · 7 comments
Closed
Assignees

Comments

@harobed
Copy link

harobed commented Feb 14, 2018

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

@h2non
Copy link
Owner

h2non commented Feb 14, 2018

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.

@steinfletcher
Copy link
Contributor

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

@h2non
Copy link
Owner

h2non commented Oct 11, 2018

@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.

@steinfletcher
Copy link
Contributor

@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 :)

@h2non h2non self-assigned this Oct 12, 2018
@h2non
Copy link
Owner

h2non commented Oct 14, 2018

@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 👍

@steinfletcher
Copy link
Contributor

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

@steinfletcher
Copy link
Contributor

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:/steinfletcher/gock/blob/feature/diagram/sequence-diagram.html

@h2non h2non closed this as completed in #38 Oct 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants