enable unit testing of http handlers by way of test cfg-only mock helpers

[softprops]

Issue #, if available:

Description of changes:

In a discussion on unit testing in softprops/serverless-aws-rust-multi#1 (comment) it came to mind that one drawback of the current interface for the http lambda crate was that there is no way to manually create a request to test a handler that depends on the data returned from one of the RequestExt methods. This is partially intentional as the extension types are a private impl detail.

I'm deeply sympathetic the limitations of this drawback this because I'm a big believer in tests. This pull represents an interface that still respects that and should only be exported in cfg(test) builds making them available in unit test contexts only.

Here's a sketch of what this pull makes possible

#[macro_use] extern crate maplit;

use lambda_http::{Request, RequestExt};
use lambda_runtime::Context;

#[cfg(test)]
mod tests {
  #[test]
  fn handler_test() {
     let request = Request::default()
        .with_path_parameters(hashmap! {
           "foo".into() => vec!["bar".into()]
        })
       .with_query_string_parameters(hashmap! {
           "foo".into() => vec!["bar".into()]
        })
       .with_stage_variables(hashmap! {
           "foo".into() => vec!["bar".into()]
        });
    
     match handler(request, Context::default()) {
        // tests here ...
      }
  }
}

By submitting this pull request

• I confirm that my contribution is made under the terms of the Apache 2.0 license.
• I confirm that I've made a best effort attempt to update all relevant documentation.

[softprops]

I would have used mut self here except that syntax is being phased out. See this post for more details on why

[softprops]

notes the cfg(test) attributes. the net effect is that these methods are only available for tests and keeps the surface for the runtime interface focused on read only access

[softprops]

/cc @wbprice

[softprops]

the travis error doesn't seem related to these changes

[davidbarsky]

No, the travis error's related to toolstate. I think these values can and should be constructed in non-test targets as well. Do you think it makes sense to provide From implementations from the standard http types?

[softprops]

I think these values can and should be constructed in non-test targets as well. Do you think it makes sense to provide From implementations from the standard http types?

These are extensions to the standard http types specific to aws alb/api gateway. There isn't really a corollary in the http crate to path parameters/query string parameters/stage variables.

The reason why I don't want to expose these for non test targets is because there's not actually a usecase for that. Its the trigger that provides these so the current interfaces expose just that, a read only interface. The only use case where'd you want to populate these your self is in a test context.

[softprops]

I'm starting to see the same travis error in my other projects. I learned in my journey theres a few rust project links that are helpful to keep an eye on listed here rust-lang/rustfmt#3404 (comment)

[softprops]

@davidbarsky just checking to see if anyone still reviewing this. the travis error is unrelated to the changes https://travis-ci.org/awslabs/aws-lambda-rust-runtime/jobs/493590501 but does look like the rustfmt gone missing thats trolling everyone's nightly builds. I could open a separate pull to fix that for this projects build if you want

[davidbarsky]

@softprops Apologies for the delay. I think this is a good PR and conservatively-scoped—I'll merge this one in.