Consider improving encapsulation of data related to request

[jthomerson]

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

[jeremydaly]

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.