8000 Consider improving encapsulation of data related to request · Issue #96 · jeremydaly/lambda-api · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

Consider improving encapsulation of data related to request #96

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.

Sign up for GitHub

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

Jump to bottom
Closed
jthomerson opened this issue Jan 17, 2019 · 1 comment
Closed

Consider improving encapsulation of data related to request #96

jthomerson opened this issue Jan 17, 2019 · 1 comment
Labels
enhancement

Comments

@jthomerson
Copy link
Contributor

In trying to write tests for lib/request.js, I opened test/requests.js to add tests. The tests for the Request class are all actually running by means of creating an API, setting up middleware, and then calling api.run(evt, context, cb), and then testing the response. That seemed odd to me, so I tried to figure out how to test a request in isolation. Then I realized that you really couldn't; a request expects to be passed an app as its only constructor arg, and it gets the event, context, etc, from the app.

Proposal: It seems counter-intuitive to me that every request has its event, context, and callback set on the application. It would seem more natural if the Request class was more like new Request(app, evt, context, cb). Then the request class and all its methods (the complex parsing stuff it does) could be tested in isolation. (The tests that are currently in test/requests.js are still good, but they're not really unit testing the request itself - they're more akin to an integration test).
@jthomerson jthomerson mentioned this issue Jan 17, 2019
Open
@jeremydaly
Copy link
Owner

The initial purpose of the Request class was to simply parse and format the request. And since the results can all be directly measured by instantiating and calling an API route, it seemed the most logical way to approach testing. There was little incentive to build separate unit tests, since EVERY API execution needed to parse a request.

It would be possible to instantiate a Request independently by stubbing the app, but you would have to assign the _event and context (and possibly other) values to it. A lot of refactoring went in to v0.10, so I'm sure there are plenty of additional optimizations like this that could help.

I've been meaning to sketch out a way to break up the application into smaller components as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jthomerson @jeremydaly
0