Serverless is more than a cloud computing execution model. It changes the way we plan, build, and deploy apps. But it also changes the way we test our apps.

无服务器不仅仅是云计算执行模型。 它改变了我们计划，构建和部署应用程序的方式。 但这也改变了我们测试应用程序的方式。

Meet Alex. Alex is an ordinary JavaScript developer, focused on Node.js lately.

认识亚历克斯。 Alex是普通JavaScript开发人员，最近专注于Node.js。

Over the last couple of months, his good friends, Anna and Jeff, are always talking about that serverless thingy. Even through they are annoying from time to time, he likes the idea of serverless apps. He even deployed few simple functions to AWS Lambda and Azure at some point.

在过去的几个月中，他的好朋友Anna和Jeff一直在谈论无服务器的问题。 即使他们不时惹恼他们，他也喜欢无服务器应用程序的想法。 甚至在某个时候，他甚至向AWS Lambda和Azure部署了一些简单的功能。

At some point, Alex and his team got a new project. After some analysis, Alex thought that it would be the perfect fit for serverless. He presented the idea to his team. Some of the team members were excited, one of them didn’t like it, but most of them didn’t have a strong opinion. So, they decided to give it a try — the project wasn’t too big, and the risk was low.

在某个时候，Alex和他的团队得到了一个新项目。 经过分析，Alex认为这将非常适合无服务器。 他向团队提出了这个想法。 一些团队成员很兴奋，其中一个人不喜欢它，但是大多数人对此没有强烈的意见。 因此，他们决定尝试一下-该项目规模不大，风险也很低。

The team read about serverless, and they got an idea how to structure their new app. But no one was sure how they should fit serverless into their common development process.

团队阅读了有关无服务器的内容，他们了解了如何构建新应用程序。 但是没有人知道他们应该如何将无服务器应用到他们的通用开发过程中。

At that moment, their process looks like this:

那时，他们的流程如下：

1. They analyze a new feature.他们分析了一个新功能。
2. For less complex features, they start with the code, then they run it locally and add some tests in the end.对于不太复杂的功能，他们从代码开始，然后在本地运行它，最后添加一些测试。
3. For more complex features, they do their version of TDD: they start with tests, then write the code, and test it locally.对于更复杂的功能，他们使用TDD版本：从测试开始，然后编写代码，然后在本地对其进行测试。
4. When the feature is ready, it goes to the CI tool that deploys it to the testing environment.功能就绪后，将转到将其部署到测试环境的CI工具。
5. Then the QA team takes a new feature for another round of manual testing. If everything looks good, the app goes through CI to production.然后，质量检查小组将一项新功能用于另一轮手动测试。 如果一切看起来不错，则该应用将通过CI进行生产。

They decided to start step by step, and then solve the problems as they encountered them.

他们决定逐步开始，然后解决遇到的问题。

They picked a small feature, and as it was simple, they started with the code. When the coding part was ready, they hit the first roadblock: how do you run serverless applications locally?

他们选择了一个小功能，并且很简单，他们从代码开始。 当编码部分准备就绪时，他们遇到了第一个障碍：如何在本地运行无服务器应用程序？

本地测试 (Local testing)

With serverless apps, you don’t manage the infrastructure. Sounds great, but how do you then run your application locally? Can you even do that?

使用无服务器应用程序，您无需管理基础架构。 听起来不错，但是如何在本地运行应用程序？ 你能做到吗？

Depending on your app and serverless vendor, you can run some parts of your app locally. To do so, you can use some of the following tools and techniques:

根据您的应用程序和无服务器供应商，您可以在本地运行应用程序的某些部分。 为此，您可以使用以下一些工具和技术：

• Azure Functions Core Tools (for Azure functions)

  Azure Functions核心工具 (用于Azure函数)

• AWS SAM CLI (for AWS Lambda apps built using AWS SAM)

  AWS SAM CLI (适用于使用AWS SAM构建的AWS Lambda应用程序)

• Third-party tools (ie. localstack)

  第三方工具(即localstack )

• docker-lambda for AWS Lambda local simulation

  docker-lambda用于AWS Lambda本地模拟

• Run Node.js function locally在本地运行Node.js函数

Of course, the list is not complete — there are more tools, and we see new tools almost every day now.

当然，列表并不完整-有更多工具，而且我们几乎每天都在看到新工具。

Most of these tools have certain limitations. They can simulate serverless functions and a few other services, such as API Gateway. But what about permissions, auth layer, and other services?

这些工具大多数都有一定的局限性。 他们可以模拟无服务器功能和其他一些服务，例如API网关。 但是权限，身份验证层和其他服务呢？

Local testing helps with quick validations to make sure your function works. But is there a better way to make sure your serverless app is working as intended? Yes there is. The first and most important step is: write tests.

本地测试有助于快速验证，以确保您的功能正常运行。 但是，有没有更好的方法来确保无服务器应用程序按预期运行？ 就在这里。 第一步也是最重要的一步是：编写测试。

So Alex and his team tried their first function locally, and as it seemed to be working. Then they went to the next step.

因此，亚历克斯(Alex)和他的团队在本地尝试了他们的第一个功能，并且看起来很有效。 然后他们进入了下一步。

自动化测试 (Automated tests)

Alex and his team just switched to Jest for testing their Node.js applications. They still do a lot of front end, so they want to use the same tools for the full stack whenever they can. Can they use Jest for testing serverless apps too? And what should they test?

Alex和他的团队刚刚切换到Jest来测试其Node.js应用程序。 他们仍然做很多前端工作，因此他们希望在可能的情况下为整个堆栈使用相同的工具。 他们也可以使用Jest测试无服务器应用程序吗？ 他们应该测试什么？

After a quick investigation, they realized that they can use their favorite Node.js testing tools. Jest, Jasmine, Mocha and others work fine with serverless.

经过快速调查，他们意识到可以使用自己喜欢的Node.js测试工具。 Jest，Jasmine，Mocha和其他服务器在无服务器情况下可以正常工作。

您应该在无服务器应用程序中测试什么？ (What should you test in a serverless app?)

With their Node.js apps, Alex and his team follows the three-tier test automation pyramid. The test pyramid was first mentioned by Mike Cohn in his book “Succeeding with Agile”.

Alex及其团队使用他们的Node.js应用程序遵循三层测试自动化金字塔。 迈克·科恩(Mike Cohn)在他的著作《 敏捷的成功 》中首次提到了测试金字塔。

As the test pyramid defines, they have:

正如测试金字塔定义的那样，它们具有：

• A lot of unit tests, because they are the cheapest (fastest to write and run)很多单元测试，因为它们是最便宜的(编写和运行最快)
• Fewer integration tests, because they are more expensive, and they take more time to run更少的集成测试，因为它们更昂贵，并且运行时间更长
• A few UI tests, because they are the most expensive (requires some GUI tool) and slowest to run一些UI测试，因为它们是最昂贵的(需要一些GUI工具)并且运行最慢

Besides these, they also have manual session-based testing, done by their QA team.

除了这些，他们还具有由质量检查小组进行的基于会话的手动测试。

How does serverless affect the test automation pyramid?

无服务器如何影响测试自动化金字塔？

The answer depends on the tier. But the test pyramid looks less like the Egyptian pyramids, and more like the Mayan pyramids.

答案取决于层级。 但是测试金字塔看起来不太像埃及金字塔 ，更像玛雅金字塔 。

The unit tests layer is not affected a lot. Unit tests are still the cheapest to write and run, but the units can be smaller.

单元测试层影响不大。 单元测试仍然是编写和运行最便宜的方法，但是单元可以更小。

Integration tests layer becomes more important than ever, because serverless apps relies heavily on integrations. It is also cheaper, because having a serverless database just for testing is cheap. So, in a serverless “test pyramid” you need to have more integration tests.

集成测试层比以往任何时候都变得更加重要，因为无服务器应用程序严重依赖于集成。 它也更便宜，因为拥有仅用于测试的无服务器数据库很便宜。 因此，在无服务器的“测试金字塔”中，您需要进行更多的集成测试。

GUI tests layer is also cheaper and faster, because of cheaper parallelization.

由于并行化便宜，GUI测试层也越来越便宜。

Manual testing layer stays the same. But serverless can help you to improve it slightly. We’ll go into the details on that later.

手动测试层保持不变。 但是，无服务器可以帮助您进行一些改进。 稍后我们将详细介绍。

Alex and his team finally had some idea where to focus. The next problem was how to write a function to test them more easily.

亚历克斯和他的团队终于对集中精力有了一些想法。 下一个问题是如何编写函数来更轻松地对其进行测试。

如何编写可测试的无服务器功能 (How to write a testable serverless functions)

You need to think about the following risks while you are writing a serverless function:

编写无服务器功能时，您需要考虑以下风险：

• Configuration risks Are the database and table correct? Or, do you have access rights?

  配置风险数据库和表是否正确？ 或者，您是否具有访问权限？

• Technical workflow risks Are you parsing and using the incoming request as you should? Or, are you handling successful responses and errors correctly?

  技术工作流程风险 您是否应该解析和使用传入的请求？ 或者，您是否正确处理成功的响应和错误？

• Business logic risks Did you follow all the business logic rules that your application has?

  业务逻辑风险 您是否遵循应用程序具有的所有业务逻辑规则？

• Integration risks Are you reading the incoming request structure correctly? Or are you storing the order to the database correctly?

  集成风险您是否正确阅读传入的请求结构？ 还是您将订单正确存储到数据库中？

To confirm that your serverless function is working correctly, you need to test all these risks.

为了确认无服务器功能是否正常运行，您需要测试所有这些风险。

You could test each of these as you did for the integration tests. But setting up and configuring the service each time you want to test for one of these risks isn’t optimal. As my friend Aleksandar Simovic loves to say:

您可以像对集成测试一样对它们中的每一个进行测试。 但是，每次要测试其中一种风险时，设置和配置服务都不是最佳选择。 正如我的朋友Aleksandar Simovic喜欢说的：

Imagine if testing automobiles was done that way. That would mean that every time you wanted to test a single screw or even a mirror in a car, you would have to assemble and then disassemble the whole car.

试想一下，是否以这种方式测试汽车。 这意味着每次您要测试汽车中的单个螺钉甚至镜子时，都必须组装然后拆卸整个汽车。

To make the app more testable, the clear solution is to break up your function into several smaller ones.

为了使该应用程序更具测试性，明确的解决方案是将您的功能分解为几个较小的功能。

One of the great ways to do so is applying Hexagonal Architecture to your serverless functions.

做到这一点的好方法之一就是应用六角建筑 您的无服务器功能。

Hexagonal Architecture, or Ports and Adapters, is a form of application architecture that promotes the separation of concerns through layers of responsibility. As its creator, Alistair Cockburn, explains:

六边形体系结构(或端口和适配器 )是一种应用程序体系结构，它通过职责层促进关注点的分离。 创建者Alistair Cockburn解释说：

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

允许应用程序同样由用户，程序，自动测试或批处理脚本驱动，并与最终的运行时设备和数据库隔离地进行开发和测试。

So, how does that apply to serverless functions?

那么，这如何适用于无服务器功能？

As Alex and his team use AWS, they ended up with a structure like the following:

Alex和他的团队使用AWS时，最终得到了如下结构：

• Function business logic exposes few “ports” (or expects few arguments). For example, one for an incoming event, one for permanent storage, and one for notifications.函数业务逻辑公开很少的“端口”(或期望很少的参数)。 例如，一个用于传入事件，一个用于永久存储，另一个用于通知。
• They have two adapters for the event that triggers a function, one for the real AWS Lambda trigger and another one for local testing.他们有两个用于事件触发功能的适配器，一个用于真实的AWS Lambda触发器，另一个用于本地测试。
• They have several adapters for permanent storage and notifications. For example, DynamoDB table adapter and in-memory adapter.它们具有用于永久存储和通知的多个适配器。 例如，DynamoDB表适配器和内存适配器。

Alex and his team were happy that they were moving forward. But before we move on, let’s see how Hexagonal Architecture affects each tier of the test pyramid.

亚历克斯和他的团队为前进感到高兴。 但是在继续之前，让我们看看六角结构如何影响测试金字塔的每一层。

单元测试 (Unit testing)

Unit tests stayed the same. But it’s easier to write unit tests because of Hexagonal Architecture. They can simply use a local adapter or mock as an adapter to test the function business layer in isolation.

单元测试保持不变。 但是由于采用了六角架构，因此编写单元测试更加容易。 他们可以简单地使用本地适配器或模拟作为适配器来单独测试功能业务层。

整合测试 (Integration testing)

Integration tests benefited a lot from Hexagonal Architecture. They were able to fully test integrations that they own. Third-party integrations are simulated with other adapters.

集成测试从六角结构中受益匪浅。 他们能够完全测试自己拥有的集成。 第三方集成是与其他适配器一起模拟的。

How does that work in practice?

在实践中如何工作？

Each of their serverless functions has lambda.js and main.js files. The main file contains the business logic of a serverless function. And the lambda.js file is in charge of wiring the adapters and invoking the main.js file.

他们的每个无服务器功能都有lambda.js和main.js文件。 主文件包含无服务器功能的业务逻辑。 lambda.js文件负责连接适配器并调用main.js文件。

The main file has its own unit and integration tests. But its integration tests don’t test full integration with end services, such as AWS S3, because that would slow them down. Instead, they use an in-memory adapter to test the function with file storage integration.

主文件具有其自己的单元和集成测试。 但是其集成测试不会测试与最终服务(例如AWS S3)的完全集成，因为这会降低它们的速度。 相反，他们使用内存适配器来测试文件存储集成的功能。

AWS S3 integration is done through the FileRepository, which has its own unit and integration tests. Integration tests checks use AWS S3 to be sure that the end integration actually works.

AWS S3集成通过FileRepository完成，该文件具有自己的单元和集成测试。 集成测试检查使用AWS S3来确保最终集成确实有效。

As opposed to main.js, the lambda.js file doesn’t have tests, because most of the time it has just a few lines of code.

与main.js相对， lambda.js文件没有测试，因为在大多数情况下，它只有几行代码。

This approach is like the technique the MindMup team is using for testing serverless functions. With it, you can easily test integrations of your functions, and still make your integration tests faster.

这种方法类似于MindMup团队用于测试无服务器功能的技术。 使用它，您可以轻松地测试功能的集成，并且仍然可以使集成测试更快。

GUI测试 (GUI testing)

As Alex and his team were building a back end for the app, the GUI tests tier was not relevant. But as they learned more about serverless, they realized that they could use it to improve the GUI tests tier for the other apps they were working on.

由于Alex和他的团队正在为该应用构建后端，因此GUI测试层并不重要。 但是随着他们对无服务器的更多了解，他们意识到可以使用它来改善他们正在处理的其他应用程序的GUI测试层。

UI tests are expensive and slow, because they run in the browser. But, serverless is cheap and it scales fast.

UI测试既昂贵又缓慢，因为它们在浏览器中运行。 但是，无服务器很便宜并且可以快速扩展。

If they could run a browser in AWS Lambda, they would gain cheap parallelization. That would make their UI tests cheaper and faster.

如果他们可以在AWS Lambda中运行浏览器，则将获得廉价的并行化。 这将使他们的UI测试更加便宜和快捷。

But, can you run a browser, such as Chrome, inside a serverless function?

但是，您可以在无服务器功能内运行浏览器(例如Chrome)吗？

Yes! And it is easy with the help of a tools such as Serverless Chrome, Chromeless, and Puppeteer.

是! 借助无服务器Chrome ， Chromeless和Puppeteer之类的工具，这很容易。

A combination of serverless and headless browsers can bring us a new generation of UI testing tools. We can already see and try some of them, such as Appraise.

无服务器浏览器和无头浏览器的组合可以为我们带来新一代的UI测试工具。 我们已经可以看到并尝试其中的一些方法，例如Appraise 。

CI / CD (CI / CD)

As Alex and his team tested their first serverless function, it was time to deploy the code to the testing environment. That brought up a new question: how can they use CI/CD tools to deploy their serverless app?

在Alex及其团队测试其第一个无服务器功能时，是时候将代码部署到测试环境了。 这就提出了一个新问题：他们如何使用CI / CD工具来部署其无服务器应用程序？

The answer is simple: they can use a CI tool to run the tests and deploy the app. To deploy the app, use any popular tool, such as Claudia.js, AWS SAM, and Serverless Framework.

答案很简单：他们可以使用CI工具来运行测试和部署应用程序。 要部署该应用程序，请使用任何流行的工具，例如Claudia.js ， AWS SAM和Serverless Framework 。

You can still use your favorite CI tool (like Jenkins, TravisCI or SemaphoreCI), or if you want to stick with AWS, you can try AWS CodeBuild.

您仍然可以使用自己喜欢的CI工具(例如Jenkins ， TravisCI或SemaphoreCI )，或者，如果要坚持使用AWS，则可以尝试AWS CodeBuild 。

手动测试 (Manual testing)

Even through manual testing is not directly affected by serverless, the team found a way to improve their QA process.

即使通过手动测试不受无服务器的直接影响，该团队也找到了改进其质量检查流程的方法。

Stages and deployments of serverless app are cheap and often fast to setup. Also, with serverless, you don’t pay for the app if no one is using it.

无服务器应用程序的阶段和部署很便宜，并且通常可以快速设置。 此外，使用无服务器，如果没有人使用它，则无需为该应用付费。

This means that having a testing environment has never been cheaper!

这意味着拥有测试环境从未如此便宜！

Also, with serverless, you can often promote the function from one stage to another. This means that your QA team can test a function, and when they confirm that it works, you can promote the same function to production.

此外，与无服务器，你经常可以促进功能从一个阶段到另一个阶段。 这意味着您的质量检查团队可以测试一项功能，当他们确认该功能有效时，您可以将该功能推广到生产中。

超越测试 (Beyond testing)

Alex and his team shipped their first serverless function to pre-production, and the team was happy that they learned how to test serverless apps.

Alex和他的团队将其第一个无服务器功能交付给了预生产，并且团队很高兴他们学会了如何测试无服务器应用程序。

They continued using serverless on the project, and introduce it to few other projects. Alex joined his friends Anna and Jeff, as a third, sometimes annoying, serverless preacher. And they lived happily ever after.

他们继续在该项目上使用无服务器，并将其介绍给其他几个项目。 亚历克斯(Alex)和他的朋友安娜(Anna)和杰夫(Jeff)作为第三位，有时是令人讨厌的，无服务器的传教士加入。 从此他们过着幸福的生活。

后记 (Post-script)

But even though their app was well-tested, something happened overnight.

但是，即使他们的应用程序经过了严格的测试，但一夜之间还是发生了一些事情。

After an investigation, they found out that one of the integrations changed. They learned that testing is important for serverless apps, but it’s not enough.

经过调查，他们发现其中一个集成发生了变化。 他们了解到，测试对于无服务器应用程序很重要，但这还不够。

As serverless apps heavily depend on integrations, the risk shifts from your code to the integrations. And, to be able to catch integration changes and react fast, your app needs proper monitoring.

由于无服务器应用程序严重依赖集成，因此风险从代码转移到集成。 而且，为了能够捕获集成更改并快速做出React，您的应用程序需要适当的监控。

Fortunately, there are more and more serverless monitoring tools on the market every day. Some of the good and popular options are IOpipe, Thundra, Dashbird, and Epsagon.

幸运的是，每天市场上都有越来越多的无服务器监视工具。 IOpipe ， Thundra ， Dashbird和Epsagon是一些不错的受欢迎的选择。

But, serverless apps often have a thick client, which means that back end monitoring is not enough. You need a similar tool for your front end. This market has a lot of nice tools too, such as Sentry and Rollbar.

但是，无服务器应用程序通常具有胖客户端，这意味着后端监视还不够。 您的前端需要类似的工具。 这个市场也有很多不错的工具，例如Sentry和Rollbar 。

But in the spirit of serverless, we created an open source error-tracking app called Desole. It is a serverless app you can install in your AWS account. It enables organisations to track application exceptions and errors without having to choose between the convenience of software-as-a-service and the security of a self-hosted solution. You can check it out here: https://desole.io.

但是本着无服务器的精神，我们创建了一个名为Desole的开源错误跟踪应用程序。 这是一个无服务器应用程序，您可以安装在您的AWS账户中。 它使组织能够跟踪应用程序异常和错误，而不必在软件即服务的便捷性和自托管解决方案的安全性之间进行选择。 您可以在这里查看： https : //desole.io 。

All illustrations are created using SimpleDiagrams4 app.

所有插图都是使用SimpleDiagrams4应用程序创建的。

If you want to learn more about testing and building serverless apps using Node.js and AWS, check out “Serverless Applications with Node.js”, the book I wrote with Aleksandar Simovic for Manning Publications:

如果您想了解有关使用Node.js和AWS测试和构建无服务器应用程序的更多信息，请查看我与Aleksandar Simovic为Manning Publications撰写的书“使用Node.js的无服务器应用程序”：

Serverless Applications with Node.jsA compelling introduction to serverless deployments using Claudia.js.www.manning.com

带有Node.js 的 无服务器应用程序有关 使用Claudia.js的无服务器部署的引人注目的介绍。 www.manning.com

The book will teach you more about serverless testing, with code examples, but you’ll also learn how to build and debug a real world serverless API (with DB and authentication) using Node and Claudia.js. And you’ll learn how to build chatbots, for Facebook Messenger and SMS (using Twilio), and Alexa skills.

该书将通过代码示例向您介绍有关无服务器测试的更多信息，但您还将学习如何使用Node和Claudia.js构建和调试真实的无服务器API(具有数据库和身份验证)。 您还将学习如何为Facebook Messenger和SMS(使用Twilio)以及Alexa技能构建聊天机器人。

翻译自: https://www.freecodecamp.org/news/the-best-ways-to-test-your-serverless-applications-40b88d6ee31e/