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

Automatic mock responses #114

Open
alfirin opened this issue Sep 4, 2019 · 2 comments
Open

Automatic mock responses #114

alfirin opened this issue Sep 4, 2019 · 2 comments

Comments

@alfirin
Copy link

alfirin commented Sep 4, 2019

Is-it possible to have an option or a plugin to automatically returns the answers provided in the swagger specification file inside a controller?

That will avoid us to create the same thing from the Swagger specification file and inside the controller.

Thanks a lot for your help.

@jwalton
Copy link
Contributor

jwalton commented Sep 11, 2019

You're not the first person to ask about this. It should definitely be possible.

We have infrastructure for plugins already which should have most of what you'd need to do this. Off the top of my head, if I was going to do this, I'd traverse all the paths in the apidoc at the top level of makeExegesisPlugin() (because this is where you're allowed to modify the apidoc) and replace all the x-exegesis-controllers with something like mockController, and for each one I'd add a new method to my mockController object which just returns whatever the first defined response is for that path.

The first tricky bit is constructing a valid response; if there's an example at the top level of the schema object, you can just steal that, but if there isn't you'd have to use something like json-schema-traverse to walk the schema and construct a valid example as you go. swagger-ui does something similar to generate examples, so you might be able to steal some code from them, but it might be faster to just rewrite this from scratch (maybe make it a package in it's own right... Or, now that I say that, maybe there's already a package out there that does something like this!)

The second tricky bit is, I'm not sure where you'd get a chance to insert the mockController. Again, off the top of my head, I'd suggest makeExegesisPlugin() should be passed an { apiDoc, options } object, with the raw objects that were passed into Exegesis, and then you could add your options there. The idea would be to let plugins modify the options object before it gets passed to compileOptions, because that does a bunch of sanity checking, adds default options, sanitizes the passed in bodyParsers, etc... and I don't think we'd want plugins to be mucking about with options after we do all of that. Might need a tiny bit of refactoring to make sure all the plugins get build prior to the call to compileOptions(), but that shouldn't be too bad.

I wouldn't mind taking a stab at something like this, but I can tell you we're a little short staffed at work right now, and I'm pretending to be DevOps and learning Kubernetes, so it might be a little while before I get a chance. But if you think that's enough to get you started, feel free to give it a go - I'm happy to answer any questions if you get stuck. :)

@jwalton
Copy link
Contributor

jwalton commented Sep 11, 2019

json-schema-faker might be a good place to start for generating responses, although I bet it ignores the example keyword, because I'm pretty sure that's OAS3 specific.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants