AWS Lambda handleRequest方法测试时Jackson反序列化失败问题排查与解决方案咨询

你遇到的核心问题是测试时传入的输入类型和AWS Lambda运行时实际传入的类型不一致：

• 在AWS控制台触发Lambda时，平台会自动将你输入的JSON字符串解析为一个LinkedHashMap（或对应结构的Java对象），再作为input参数传给handleRequest方法。
• 但你的测试代码直接传入了JSON字符串，Jackson在尝试将这个字符串反序列化为Request类时，找不到对应的String参数构造器，因此抛出了报错信息里的异常。

你的testInput构造方式本身没有语法问题，但因为传入的类型不符合Lambda运行时的实际输入类型，才导致反序列化失败。

这里提供几种可行的测试输入构造方式，帮你解决这个问题：

1. 模拟Lambda运行时的输入类型（将JSON转为Map） #

用Jackson把JSON字符串解析成LinkedHashMap（也就是Lambda实际会传入的对象类型），再传给handleRequest：

@Test
public void test_handleRequest() throws IOException {
    String testInputJson = "{\"fieldA\":\"fieldAValue\",\"fieldB\":\"fieldBValue\",\"fieldC\":\"fieldCValue\",\"fieldList\":[{\"subFieldA\":\"subFieldAValue\", \"subFieldB\":\"subFieldBValue\", \"subFieldC\":\"subFieldCValue\", \"subFieldD\":\"subFieldDValue\", \"subFieldE\":\"subFieldEValue\"}]}";
    
    // 把JSON字符串转成LinkedHashMap，模拟Lambda运行时的输入对象
    Object lambdaInput = OBJECT_MAPPER.readValue(testInputJson, Object.class);
    
    handleRequest(lambdaInput, null);
    
    // 后续断言逻辑
    ...
}

2. 直接构造Request对象实例（更简洁可靠） #

跳过JSON解析步骤，直接创建Request类的对象，这样完全避免序列化/反序列化的问题，测试逻辑也更清晰：

@Test
public void test_handleRequest() {
    // 构造子对象
    SubField subField = new SubField();
    subField.setSubFieldA("subFieldAValue");
    subField.setSubFieldB("subFieldBValue");
    subField.setSubFieldC("subFieldCValue");
    subField.setSubFieldD("subFieldDValue");
    subField.setSubFieldE("subFieldEValue");
    
    // 构造Request对象
    Request testRequest = new Request();
    testRequest.setFieldA("fieldAValue");
    testRequest.setFieldB("fieldBValue");
    testRequest.setFieldC("fieldCValue");
    testRequest.setFieldList(List.of(subField));
    
    handleRequest(testRequest, null);
    
    // 后续断言逻辑
    ...
}

注：这里假设你的Request和SubField类有对应的setter方法，或者可以通过构造器直接初始化。

3. 修改handleRequest的反序列化逻辑（可选） #

如果想兼容字符串类型的输入（比如测试时传字符串），可以修改你的反序列化代码，先判断输入的类型：

@Override
public Response handleRequest(Object input, Context context) throws IOException {
    Request request;
    if (input instanceof String) {
        // 如果是字符串，直接解析
        request = OBJECT_MAPPER.readValue((String) input, Request.class);
    } else {
        // 否则按照原来的逻辑处理Lambda运行时的输入
        request = OBJECT_MAPPER.readValue(OBJECT_MAPPER.writeValueAsBytes(input), Request.class);
    }
    
    // 业务逻辑代码
    ...
}

这种方式可以让你的测试代码保持原来的写法，同时兼容Lambda运行时的输入类型。

推荐优先使用方案2，因为直接构造对象的测试方式更直观，也避免了JSON解析可能带来的额外问题；如果需要模拟真实的Lambda输入场景，可以选择方案1；如果不想修改测试代码，那么方案3会是更便捷的选择。

内容的提问来源于stack exchange，提问作者Harshitha