測試無服務器應用程序的最佳方法

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:

那時，他們的流程如下：

They analyze a new feature.
他們分析了一個新功能。
For less complex features, they start with the code, then they run it locally and add some tests in the end.
對于不太復雜的功能，他們從代碼開始，然后在本地運行它，最后添加一些測試。
For more complex features, they do their version of TDD: they start with tests, then write the code, and test it locally.
對于更復雜的功能，他們使用TDD版本：從測試開始，然后編寫代碼，然后在本地對其進行測試。
When the feature is ready, it goes to the CI tool that deploys it to the testing environment.
功能就緒后，將轉到將其部署到測試環境的CI工具。
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技能構建聊天機器人。