How to test with the lambda macro?

[miles-po]

How do test the lambda given the example below? According to test functions, main does not exist.

use lambda::{lambda, Context};
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[lambda]
#[tokio::main]
async fn main(event: Value, _: Context) -> Result<Value, Error> {
    Ok(event)
}

#[cfg(test)]
mod tests {
    use serde_json::json;
    use super::*;

    #[test]
    fn test_lambda_handler() {

        let payload = json!({
            "val1": true,
            "val2": 42,
            "val3": "hello"
        });

        //
        //     W H A T   G O E S   H E R E   ?
        // 

    }
}

[calavera]

It might be easier if you extract the body in the main function into another async function, and then use a tokio test to verify your behavior.

Updating your example(but I have not tested it):

use lambda::{lambda, Context};
use serde_json::Value;

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[lambda]
#[tokio::main]
async fn main(event: Value, ctx: Context) -> Result<Value, Error> {
    run_main(event, ctx).await
}

async fn run_main(event: Value, _: Context) -> Result<Value, Error> {
  Ok(event)
}

#[cfg(test)]
mod tests {
    use serde_json::json;
    use super::*;

    #[tokio::test]
    fn test_lambda_handler() {
        let payload = json!({
            "val1": true,
            "val2": 42,
            "val3": "hello"
        });

        let ctx = Context{
          // set required field values here
        };

        let response = run_main(payload, ctx).await.expect("invalid error");
        assert_eq!(...)
    }
}

[miles-po]

Thank you for the fast response.

Then might not be a compelling reason to use the lambda function macro, right? You're adding an extra function either way. Just using #[tokio::main] alone and calling the handler seems like the clearer option to me rather than add the macro magic and have to create another function anyway. Your thoughts?

Is the choice down to "make it testable with a separate handler" or "use the lambda macro but make an extra function anyway if you want it testable" but not both? I'm fine with that. Just confirming.

[calavera]

Is the choice down to "make it testable with a separate handler" or "use the lambda macro but make an extra function anyway if you want it testable" but not both? I'm fine with that. Just confirming.

I prefer the macro because it's easier to remember. But it's completely a personal preference.

[softprops]

There are concrete reasons why you might not want to use the macro, one time initialization of an sdk client for instance but in general it is not unusual to have a delegate method for testing separate from the execution method.

Consider a cli separating a run method that's provided parsed arguments from a fn main() and doesn't depend on a global env. What you get it something much more unit testable. The same can be said for the practice of separating a method that can be unit tested from the execution method.

When you use the macro you actually get a method synthesized inside a std fn main() which is passed to the core lambda reactor event loop implicitly. This is not in a lexical scope you could reference in a test. This is good for rapidly prototyping and getting up and running but I typically refactor towards unit testability

[jamesmcm]

Hi,

Should this be closed since lambda-attributes has been removed in commit 5ae037e ?

Is there documentation on testing the handler function directly (i.e. now called with lambda::run()) with a test event as in the original post here? i.e. what values may need to be set in the Lambda Context?

[bahildebrand]

With the lambda attribute removed in #282 this issue can be closed.