-
-
Notifications
You must be signed in to change notification settings - Fork 282
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
Adding simple ability for multiple responses from a test server #594
base: master
Are you sure you want to change the base?
Conversation
hey thanks for this - i'll take a look when i'm at my computer :) |
@KevinJCross would you mind also provide a few bits of information and example usage for the documentation? -- the https://onsi.github.io/gomega/ one; you already documented the source code. |
hey @KevinJCross - first off thanks for this. I can see the utility of both of these and the use cases in your examples make sense. A couple of thoughts, though:
What gives me pause, though, is that both of these handlers will only work if used with server.AppendHandlers(ghttp.RespondWithMultiple(...)) they won't get the expected behavior - since the handler returned by So I wonder if there's something deeper we need to adjust in Does that make sense? Also - agreed with @thediveo that it would be good to add some additional narrative-style documentation to https://github.com/onsi/gomega/blob/master/docs/index.md That can be a good place to motivate the usecases that |
hi @onsi and @thediveo The problem is that append handlers and Set default handler does not add a "use case" the normal use case for this is for testing retries and creating a stress test with some problematic behaviour. The adding of the ResponseWithMultiple is obvious in the way it has one set of circular handlers for one single endpoint. In our case we set up a whole environment of services and responses on the single ghttp server so setting the default response to be repeated could be confusing. Most of the time Ive seen ghttp been used for single request validation server.AppendHandlers(
CombineHandlers(
VerifyRequest("GET", "/v3/something/404"),
RespondWithJSONEncoded(http.StatusNotFound, cf.CfResourceNotFound),
),
) BTW: An example of using this to test some retry behaviour: An example of using this to stress test some failure and recovery behaviour (I deved this test to find a subtle behaviour that was plaguing one of our deployments), it is a bit complicated but I had to have a repeating behaviour on one sepcific end point an have this endpoint hit by several "threads"/users at the same time. Ive used other mocking tools were you can create a "scene" or "act" (like a play) where its easy to just write a whole bunch of request responses in sequence to elicit the incorrect behavour you are trying to fix. I think this is little easier to read in sequence than the above situations. Maybe ghttp is the wrong tool for this but it was what was in hand without having to add more dependencies and thought it was usefull enought that the community might be able to re-use it. |
OK got it - it sounds like you are building out a more complete "fake server" vs focusing on individual end-points at a time. That's what As for the docs - yes what you've added will appear in godoc. Gomega also has additional documentation here which acts more as a book/tutorial than the godocs. That could be a good place to explain the use case here and to guide users on when to pick which tool in the ghttp toolbox. Lastly - scenes/acts make sense and it seems like it wouldn't be a far leap to add something like that to ghttp. If anything a scene is simply a slice of handlers or a map of routes to handlers and I could imagine rolling your own mini-DSL for that. In any event, I'm happy to pull this in. The GitHub checks went red, though, so if you could dig into that and consider updating the docs that would be great. |
Ive used this code in our project to test retry behaviour of a client we developed.
I also used the round robin version to stress test some of the client functionality to check for conection leaks and race conditions.