无服务器测试策略(上)

开始使用 AWS Lambda 和其他无服务器技术（SQS、EventBridge、Step Functions 等）的开发人员常常想知道他们应该如何测试他们的应用程序。这不仅与测试有关，更多是与 Developer eXperience (DX) 有关：
●主要标准之一通常是速度，以及它们如何缩短代码和代码结果之间的反馈循环。开发人员（及其经理）不想浪费时间等待编译、部署或测试执行。
●另一个基本标准是反馈的准确性：每个人都想要可靠的信息（没有不稳定的测试），并且相信如果测试正常，应用程序就会正常。
●最后，反馈的精确度也是确定错误或失败测试来源的关键。越精确，修正的速度就越快。
管理者通常会在这些标准之上添加一个额外的标准：成本。我已经提到浪费时间等待，这是有代价的，但是当谈到云时，在云中使用的资源也有代价。还可以包括编写自动化测试的成本。这篇博文描述了无服务器应用程序的不同自动化测试选项，以及它们在这 4 个方面的评价。我会在结论中给出推荐的“策略”。
免责声明：这篇博文代表我个人的想法，并没有得到 AWS 的认可。
免责声明 2：这篇博文并非详尽无遗，并且肯定有一些用例不适合所提出的解决方案。一种尺寸并不适合所有人！

是“测试金字塔”还是“测试蜂窝”？

本节的目的不是提供这两者的描述和比较，而是介绍一些将在下一节中有用的词汇。如果你对这两个概念不是很了解，请查看这些文章：Test Pyramid（作者 Martin Fowler）和 Testing of Microservices（作者 Spotify Engineering Team）。总之，测试金字塔表明开发人员关注“单元测试”，而蜂巢则倾向于“集成测试”。就像操作系统（Windows 与 Linux、Android 与 iOS）一样，每个操作系统都有其支持者和反对者。
我个人喜欢单元测试，因为它们超级快、超级精确而且非常便宜，因此我更喜欢金字塔，但是：
●并不是每个人都同意单元测试的相同定义，单元和集成之间的界限在哪里。我真的很喜欢 Martin Fowler 的这篇文章以及“社交测试”和“单独测试”的介绍：

我们是否将社交测试视为单元测试或集成测试？有些人会告诉单元测试应该单独验证代码，所以只有单独的测试才是真正单一的。其他一些人会争辩说模拟是异端。我想“这取决于”：我们是在谈论模拟另一个方法、另一个类还是整个 AWS 云？
●在无服务器应用程序中，更准确地说，在 Lambda 函数中，我们通常只有很少的业务逻辑，大部分代码都是由对其他 AWS 服务的调用组成的（在 S3 中检索文件，将消息推送到 SQS，……）。在这种情况下，编写大量单独测试并模拟所有这些外部调用是否有意义？
我不会参与这场争论。我只是想介绍我将在下一节中使用的这两种类型的测试。

测试选项

对于本文的其余部分，我将使用下图所示的体系结构：

API 网关、Lambda 和 Dynamo 非常标准但又不太简单的东西：Dynamo Stream、SQS 以及与遗留数据库和后端的某种连接。假设应用程序获取一些外部数据，对其进行处理、存储并与遗留后端同步。
请注意，所有选项都不是相互排斥的，我将在结论中给出我对这些选项的策略。

选项#1：单独测试

正如简介的那样，单独测试允许在没有依赖关系的情况下验证一段代码，完全与外部世界隔离。对于无服务器应用程序，这意味着你可以独立于云端测试 Lambda 函数代码。有不同的方法可以做到这一点：

1.使用模拟库

在测试等级中，你可以利用 Mockito（用于 Java）、sinon.js（用于 javascript）或 unittest.mock / moto（用于 python）等库来模拟依赖项。我们通常使用它们来模拟 AWS SDK 调用。你可以查看这篇 AWS 博客文章（“在单元测试中模拟适用于 JavaScript v3 的模块化 AWS SDK”）解释了如何使用 aws-sdk-client-mock 轻松模拟 AWS Javascript SDK v3：

如果你要模拟的依赖项数量有限（比方说一两个 SDK 调用），这种方法非常有用。不然，模拟所有内容会变得很痛苦：必须编写大量代码来指定依赖项应该执行和返回的内容，有时必须猜测响应的真实内容，并且可能会出错。这让我想到了第二种方式。

2.采用六边形架构

当 Lambda 函数增长时（注意不要鲁莽地增长）或者只是为了避免模拟 AWS 服务，可能应该考虑解耦代码：将业务逻辑与外部依赖项解耦。六边形架构可以通过使用端口和适配器将核心业务（也称为域）与外界隔离来帮助实现这一点：

端口为外部参与者提供与域（输入）交互以及域与外部参与者交互（输出）的能力。简而言之，它们是接口。适配器提供与这些外部参与者交互的逻辑，它们是实现。对于 Lambda 函数，它几乎是一样的：处理事件的函数将是一个输入适配器，而与 DynamoDB、SQS 等的交互将由输出端口和适配器处理。如果有兴趣深入研究，请查看这篇博文（“使用 AWS Lambda 开发进化架构”）。一个明显的优势是它简化了单元测试（或更准确地说是单独测试），因为不必再模拟 AWS SDK 调用。我们可以简单地为端口（假适配器）提供存根或模拟。它使代码更易于生成和阅读。它还有其他好处，比如可维护性和进化性，但它也需要一些投入。我们一无所有！

3. 使用“本地云”框架

你是否曾经梦想过在您的计算机中拥有云？这是 Localstack 的承诺：“功能齐全的本地云堆栈。离线开发和测试云和无服务器应用程序！”。看起来很有前途，不是吗？！你所要做的就是安装 (pip install localstack ) 并启动 (localstack start) LocalStack，并将 AWS SDK 端点更改为代码中的本地地址。以下是 DynamoDB 的示例：

import AWS = require('aws-sdk');let docClient = new AWS.DynamoDB.DocumentClient( {
    region: "eu-west-1",
    endpoint: "http://localhost:4566"
});

好处是不必再编写模拟：可以正在计算机上针对完整的模拟云进行测试！也不需要在云上部署任何东西，从而减少账单。
除了现实还没有达到承诺的水平。多种原因：
●Localstack 不提供 AWS 提供的所有功能（请参阅报道）。有些功能不受支持，有些功能部分受支持……显然，两家公司在各自产品上工作的工程师人数并不相同。
●在部分支持的特性上，可能（实际上是有）与云有出入。让你的测试在本地通过并不意味着它在部署到 AWS 上时也能正常工作。
●最后一点是，它的设置并不容易，你很快就会发现自己在对 LocalStack 进行故障排除而不是对您的应用程序进行故障排除，添加一些胶水代码甚至修改您自己的应用程序以针对 LocalStack 进行测试。
我建议您查看这篇文章（“是否可以在没有云的情况下进行云开发？”）以获得有关该工具的更具体的反馈。我真的很想拥有一个“功能齐全的本地云”，但目前情况并非如此，我不推荐它。

4.总结

让我们根据介绍中给出的四个标准对单独测试进行评分（0 分最低，5 分最高）：

单独测试的主要优点是非常快速和精确（均为 5）。另一方面，当我们完全隔离并使用模拟测试我们的代码时，我们无法保证它在部署后会按预期实际工作（准确性为 1）。我给出的成本是 3，因为它实际上需要人工时间来设置测试、配置模拟或构建六边形架构，而且我们都（应该）知道工程师每小时的成本远高于几个 Lambda 函数或 SQS 队列……
我的观点：
●对你的核心领域（业务逻辑）使用单独测试并避免模拟。
●喜欢干净的架构，如果不是六角形的（因为实现起来可能很繁重），至少将你的业务逻辑与所有云内容（甚至是处理程序）分开。
查看示例，我们将在第一个和最后一个 Lambda 函数中对业务层使用一些单独的测试，以验证数据处理（转换、聚合等）：

选项 #2：使用模拟 Lambda 进行社交测试

我们现在转向社交测试，其中被测试的代码并未完全与其依赖项隔离。在这种情况下不再有模拟。应用于 Lambda，这意味着该函数将实际执行对部署在真实云上的真实 AWS 服务的真实调用。
我添加了 Lambda 是“模拟”的事实：这意味着我们不调用部署在 AWS 上的真正 Lambda 函数，而是调用本地版本，以加快测试速度。实际上，可以使用 AWS SAM（sam local invoke MyFunction）或无服务器框架（serverless invoke local -f MyFunction）来执行此操作。在幕后，它使用 Docker 并引导类似于你选择的 AWS Lambda 运行时的环境（Java、Python 等），在其上部署您的代码并调用函数。
我们甚至可以更进一步，在本地测试 API 网关及其与 Lambda 的集成，并使用适当的事件（使用 sam local start-api）验证函数的调用。本地的 Step Functions 也可以完成同样的操作。这能确保函数理解并能够解析它接收到的事件（至少来自这两个服务）。
对于其他来源，必须查看事件示例的文档。 SAM 还可以生成其中的一些（大约 30 个），包括 DynamoDB 流事件和 SQS 消息事件，它们在我们的特定示例中都很有用：sam local generate-event dynamodb update / sam local generate-event sqs receive-message）。
如果我们想自动化这些类型的测试，需要编写脚本，使用 SAM CLI / Serverless CLI 执行，使用 AWS CLI 进行断言。这可能不是开发人员喜欢的（与 JUnit 或 Jest 等测试框架相比）…
因为要再次测试真实服务，这意味着我们需要部署部分基础设施（DynamoDB/SQS/RDS），这可能有点棘手，所以通常来说我们会部署所有的东西。在这种情况下，我们可能难以测试像 SQS 这样的服务，这些服务不是结束状态。有一个 Lambda 函数，它使用队列中的消息，因此无法断言该队列中是否存在消息。为了克服这个问题，我们可以创建一个没有消费者的测试队列。它对基础架构代码有一些影响。这是 SAM 模板的示例：

AWSTemplateFormatVersion: 2010-09-09
Description: >-
  sam-sqs
Transform:
- AWS::Serverless-2016-10-31
Parameters:
  # Use the command: sam deploy --parameter-overrides 'EnvType="test"'
  # to deploy the test environment (and testing SQS queue)
  # Use sam deploy only for production deployment (in a CI/CD pipeline)
  EnvType:
    Description: Environment type.
    Default: prod
    Type: String
    AllowedValues:
      - prod
      - test
    ConstraintDescription: must specify prod or test.
Conditions:
  Testing: !Equals
    - !Ref EnvType
    - test
Resources:
  RealQueue:
    Type: AWS::SQS::Queue
  TestingQueue:
    Type: AWS::SQS::Queue
    Condition: Testing # only created when the condition is met
  SQSPublisher:
    Type: AWS::Serverless::Function
    Properties:
      Description: A Lambda function that send messages to a queue.
      Runtime: nodejs16.x
      Architectures:
        - x86_64
      Handler: src/handlers/sqs-publisher.handler
      Policies:
        - AWSLambdaBasicExecutionRole
        - SQSSendMessagePolicy:
            QueueName:
              !If [Testing, !GetAtt TestingQueue.QueueName, !GetAtt RealQueue.QueueName]
      Environment:
        Variables:
          # give the appropriate queue reference according to the condition (test or not)
          SQS_QUEUE: !If [Testing, !Ref TestingQueue, !Ref RealQueue]
  SQSConsumer:
    Type: AWS::Serverless::Function
    Properties:
      Description: A Lambda function that logs the payload of messages sent to an associated SQS queue.
      Runtime: nodejs16.x
      Architectures:
        - x86_64
      Handler: src/handlers/sqs-payload-logger.handleroked
      Events:
        SQSQueueEvent:
          Type: SQS
          Properties:
            # This function remains plugged to the real queue
            Queue: !GetAtt RealQueue.Arn
      MemorySize: 128
      Timeout: 25
      Policies:
        - AWSLambdaBasicExecutionRole

查看示例，得到下图：

在定价方面，每月可以在 SQS 上免费获得 100 万条消息、100 万次 Lambda 执行和 250 万次 DynamoDB 流读取。如果 DynamoDB 和 SQS 在测试环境中相当便宜，必须谨慎选择 RDS 或 Opensearch 实例类型。 AWS 通常提供免费套餐（例如，RDS db.t2.micro 750 小时 + 20 GB 存储或 OpenSearch t3.small.search 750 小时 + 10 GB 存储）但绝对需要注意。
如果我们尝试根据以下四个标准对此类测试进行评级：

●这些测试较慢 (3)：必须部署基础设施（至少一次）并且本地调用（启动 Docker，“部署”功能）比仅运行单元测试要慢得多。
●对于Lambda 函数的交互，准确性要好一些 (3)，但仍然处于模拟环境中，没有验证权限。
●精度也相当不错 (4)，即使不是在单元测试级别，因为不只测试特定代码段，而是测试整个功能。
●至于成本，我保留 3，因为由于免费套餐，可以测试大部分架构。但自动化测试也更复杂，需要更多时间。
我的观点：
●不要将测试策略基于这些测试，不要试图基于这些测试进行强大的覆盖。它们不容易自动化并且有点慢（使用 CLI 工具）。
●你最终可以使用 SAM 或无服务器 CLI 在本地执行和调试（断点/逐步）函数。

选项#2bis：

社交测试我们无法大规模利用选项 #2 中提到的 CLI 工具并使用它们构建完整的测试工具（太慢且难以自动化）。因此，与其使用它们，不如简单地调用我们的 Lambda 函数的处理程序方法，而是保持对真实服务的调用。除了执行的操作外，图片与上一张非常相似：

这样做有两个好处：
●首先，就开发人员体验而言，这非常重要：我们可以利用标准测试库。用喜欢的语言和常用的工具编写测试要容易得多。显然可以使用 SAM CLI 生成事件并将它们导入测试资源中。
自我宣传：在 Java 中，你可以使用我编写的库 (aws-lambda-java-tests) 通过在测试中注入事件来简化测试编写：

@ParameterizedTest
@Event(value = "sqs/sqs_event.json", type = SQSEvent.class)
public void testInjectSQSEvent(SQSEvent event) {
    // test your handleRequest method with this event as parameter
}

或者更强大的：

@ParameterizedTest
@HandlerParams(
   events = @Events(folder = "apigw/events/", type = APIGatewayProxyRequestEvent.class),
   responses = @Responses(folder = "apigw/responses/", type = APIGatewayProxyResponseEvent.class))
public void testMultipleEventsResponsesInFolder(APIGatewayProxyRequestEvent event, APIGatewayProxyResponseEvent response) {
  // will inject multiple events (API GW requests) and assert responses of the Lambda 
}

●另一个优势是测试速度：没有模拟的 Lambda 环境来引导，没有 Docker。你仍然需要部署其余的基础设施，因为我们要针对云进行测试，但是一旦部署并且如果只是修改函数的代码，它仍然非常快。
对这个选项的评价与前一个选项非常相似，除了我刚刚解释的两个优点：

●速度提高，所以是 4。
●降低实施的复杂性，从而降低成本，也移动到 4。
●准确度和精密度保持不变。
我的观点：
●喜欢这种测试，因为它们在每个标准上都提供了很好的平衡。
●不要仅仅依赖这些测试，其中仍然缺少一些部分（权限、真实事件/触发器），请参阅选项 #3 或 #4。