node mocha_使用Mocha和Chai在第2部分中对Node JS进行测试

node mocha

We introduced you to the basics of testing in Node.js in the previous article. As we promised, this article picks up from where the previous one left off and discusses more advanced concepts related to testing a Node.js program.

在上一篇文章中,我们向您介绍了Node.js中的测试基础 。 正如我们所承诺的,本文将从上一个地方停下来,并讨论与测试Node.js程序有关的更高级的概念。

In this article, we are going to introduce you to the second level of testing software, to integration testing, and to common testing practices like mocking and stubbing.

在本文中,我们将向您介绍第二级测试软件,集成测试以及常见的测试实践,例如模拟和存根。

To start, let’s understand what integration testing is and why we need it.

首先,让我们了解什么是集成测试以及为什么需要它。

什么是集成测试? (What Is Integration Testing?)

Integration testing combines several units (that we tested in unit testing) and tests them as a single group. It inspects the system for bugs related to the interaction between units.

集成测试将多个单元(我们在单元测试中测试过的单元)组合在一起,并将它们作为一个整体进行测试。 它检查系统中与单元之间的交互有关的错误。

We can use integration testing to test data retrieval from databases, remote APIs, and API endpoints. The use of integration testing increases the expanse of the code covered by tests.

我们可以使用集成测试来测试从数据库,远程API和API端点的数据检索。 集成测试的使用扩大了测试涵盖的代码的范围。

Usually, integration testing is the responsibility of the developer. But it’s not rare for independent testers to carry out the testing.

通常,集成测试是开发人员的责任。 但是独立测试人员进行测试并不罕见。

使用Mocha和Chai在Node.js中进行集成测试 (Integration Testing in Node.js With Mocha and Chai)

To start with Node.js integration testing, we will use Mocha and Chai npm packages. We are going to use an Express server with REST endpoints for our testing purposes. To send HTTP requests to this server during testing, we use a new package called Chai HTTP. Make sure to install Chai HTTP using the npm install command before continuing.

要开始进行Node.js集成测试,我们将使用MochaChai npm软件包。 我们将使用带有REST端点的Express服务器进行测试。 为了在测试过程中向该服务器发送HTTP请求,我们使用了一个名为Chai HTTP的新程序包。 在继续之前,请确保使用npm install命令安装Chai HTTP。

测试异步功能 (Testing Asynchronous Functions)

When testing asynchronous functions using Mocha, we have to follow a slightly different format to the one we used in the previous tutorial. Even though I used the word new to describe this format, it is not new for a Node.js developer. We can pass a callback, or if the asynchronous function returns a promise, use promises or async/await inside the it function to deal with the asynchronous code, as we normally do in Node.js.

使用Mocha测试异步功能时,我们必须遵循与上一教程中使用的格式稍有不同的格式。 即使我使用“ ”一词来描述这种格式,但对于Node.js开发人员来说,这并不是新词。 我们可以传递一个回调,或者如果异步函数返回一个promise,则可以像在Node.js中通常那样,在it函数内部使用promise或async / await来处理异步代码。

编写测试用例以测试您的API (Write Test Cases for Testing Your API)

For your first implementation of integration testing, we are using a REST API that retrieves relevant data from a database on requests and sends them back to the client. Assume that the database (we are using a MongoDB database) and data models of the application have already been set, for the clarity of the implementation of tests.

对于您的集成测试的第一个实现,我们使用REST API,该API会根据请求从数据库中检索相关数据,并将其发送回客户端。 为了简化测试的实现,假设已经设置了数据库(我们正在使用MongoDB数据库)和应用程序的数据模型。

The POST route /dogs is used to save a new dog to the database using the data sent from the client side through a POST request. The Dog model we are using in this step has three attributes: name, age, and breed of the dog. We need to pass this data with the HTTP request to the /dog route to create a new dog.

POST route /dogs使用从客户端通过POST请求发送的数据将新的狗保存到数据库中。 我们在此步骤中使用的Dog模型具有三个属性:狗的名称,年龄和品种。 我们需要将此数据和HTTP请求一起传递到/dog路由,以创建新的Dog。

When all the routes of the API are handled, don’t forget to export the app object so that we can access the server for testing.

处理完API的所有路由后,请不要忘记导出app对象,以便我们可以访问服务器进行测试。

module.exports = app

Create a file named dogs.js inside the test directory to write the test cases for this route. Inside this file, we are testing the route to see if it responds with the results we expect. In this case, it is a confirmation that the new dog was saved to the database successfully.

在测试目录中创建一个名为dogs.js的文件,以编写此路由的测试用例。 在此文件中,我们正在测试路由,以查看其是否响应我们期望的结果。 在这种情况下,确认新狗已成功保存到数据库。

However, since we are only testing this code, we need to leave the database in its initial state after the test case is finished. So we have to delete every new record entered into the database after every test case. We can use Mocha’s afterEach hook to achieve this.

但是,由于我们仅测试此代码,因此我们需要在测试用例完成后使数据库保持其初始状态。 因此,我们必须在每个测试用例之后删除输入数据库的所有新记录。 我们可以使用Mocha的afterEach挂钩来实现此目的。

We use async/await to handle the asynchronous route-handling function. Then, we use Chai (which is using chai-http) to send a POST request to the server. We can send the body of the POST request with the request using the send method. Chai’s expect function is used to assert that the response is equal to what we expect.

我们使用async / await处理异步路由处理功能。 然后,我们使用Chai(正在使用chai-http )将POST请求发送到服务器。 我们可以使用send方法将POST请求的主体与请求一起send 。 Chai的expect函数用于断言响应等于我们的期望。

You can follow the same test process when testing much more complex API endpoints. If testing involves entering or retrieving data from a database, make sure to leave the database in its initial state using Mocha’s beforeEach and afterEach functions to enter and delete records.

测试更复杂的API端点时,可以遵循相同的测试过程。 如果测试涉及输入数据库或从数据库检索数据,请确保使用Mocha的beforeEachafterEach函数输入和删除记录,以使其处于初始状态。

与Sinon一起使用存根 (Using Stubs With Sinon)

Stubs are used as temporary replacements for functions that are used by components under testing. We use a stub to simulate the behavior of a given function. Reasons for using stubs instead of the real implementation of the function varies depending on the situation. Stubs are especially useful in unit testing when we only want to test the behavior of a single unit. In integration testing, stubs are used when the given function is not yet implemented but is required to test the current component. When several components are tied to another component going through integration testing, we can use stubs to replace some of these components if we want to test how only a few of the components work together.

存根用作测试中组件所使用功能的临时替代品。 我们使用存根来模拟给定功能的行为。 使用存根而不是功能的实际实现的原因因情况而异。 当我们只想测试单个单元的行为时,存根在单元测试中特别有用。 在集成测试中,当尚未实现给定功能但需要测试当前组件时使用存根。 当几个组件与另一个组件进行集成测试时,如果我们要测试只有几个组件如何协同工作,可以使用存根替换其中的一些组件。

Assume that the above POST /dogs route has middleware to check whether the user sending the request is logged in or not. (You can implement the isLoggedIn function appropriately.)

假设上面的POST /dogs路由具有中间件来检查发送请求的用户是否已登录。 (您可以适当地实现isLoggedIn函数。)

But at the moment, we only want to test the functionality of saving the dog’s details into the database and sending the response. In other words, we don’t want to test how the route-handling function and middleware work together for now. So we can create a stub to replace the middleware function.

但是目前,我们只想测试将狗的详细信息保存到数据库中并发送响应的功能。 换句话说,我们现在不想测试路由处理功能和中间件如何协同工作。 因此,我们可以创建一个存根来替换中间件功能。

We are using the npm package named Sinon to create stubs for our Node.js program. You should go ahead and install the package to your application before continuing.

我们正在使用名为Sinon的npm软件包为Node.js程序创建存根。 您应该继续并将软件包安装到应用程序中,然后再继续。

We use Sinon’s callsFake function to create the middleware stub. We create this stub before each test case using the beforeEach hook.

我们使用Sinon的callsFake函数来创建中间件存根。 我们在每个测试用例之前使用beforeEach挂钩创建此存根。

We need to reimport the app object before each test case, so we place that inside the beforeEach hook as well. After every test case, we need to restore the stub.

我们需要在每个测试用例之前重新导入该应用程序对象,因此我们也将其放置在beforeEach挂钩中。 在每个测试用例之后,我们需要还原存根。

用Nock模拟HTTP请求 (Mocking HTTP Requests With Nock)

If the component under testing has to retrieve data from an external API or a service, it needs to send an HTTP request to this API/service and wait for the response to arrive. If we are not explicitly testing the connectivity to this API, not sending an actual request to the external API reduces the testing time and guarantees that the test does not fail because of reasons like poor network connectivity. If we are not sending an actual request to the API, we need to fake this request during testing, and this practice is called mocking HTTP requests.

如果被测组件必须从外部API或服务中检索数据,则需要向该API /服务发送HTTP请求并等待响应到达。 如果我们未明确测试与此API的连接性,则不向外部API发送实际请求会减少测试时间,并保证测试不会因网络连接不良等原因而失败。 如果我们没有向API发送实际请求,则需要在测试期间伪造该请求,这种做法称为模拟HTTP请求。

In this tutorial, we use another npm module named Nock to mock HTTP requests to external APIs. It intercepts external requests and allows us to return custom responses to suit a particular test case.

在本教程中,我们使用另一个名为Nock的 npm模块来模拟对外部API的HTTP请求。 它拦截外部请求,并允许我们返回自定义响应以适合特定的测试用例。

Assume that our API has the route GET /dogs/:breed. It returns the subbreeds of a given dog breed by sending a request to the Dog API . (https://dog.ceo/api/breed//list). Our application server sends a GET request to the Dog API, and the data returned from the Dog API is then sent back to the client.

假设我们的API的路由为GET /dogs/:breed 。 通过向Dog API发送请求,它返回给定犬种的子品种。 ( https://dog.ceo/api/breed/ / list)。 我们的应用服务器将GET请求发送到Dog API,然后将Dog API返回的数据发送回客户端。

We use the package Superagent to send a request to the external API.

我们使用Superagent软件包将请求发送到外部API。

It retrieves the name of the breed from the URL and sends a GET request to the Dog API to get the subbreeds.

它从URL检索品种的名称,并将GET请求发送到Dog API以获取子品种。

Now we can test this route for possible bugs. Since we mock the request to the external API and send a custom response during testing, we need to save this custom response in a file to be able to retrieve it whenever we want. I saved it inside a file named response.js inside the test directory.

现在,我们可以测试此路线是否存在错误。 由于我们模拟了对外部API的请求并在测试过程中发送了自定义响应,因此我们需要将此自定义响应保存在文件中,以便能够在需要时检索它。 我将其保存在测试目录中名为response.js的文件中。

Let’s write the test case for the above route. Similar to what we did before, here we are defining the mock HTTP request to send using Nock inside a beforeEach hook.

让我们为上述路由编写测试用例。 与之前的操作类似,这里我们定义了一个模拟HTTP请求,该请求将使用Nock在beforeEach挂钩中发送。

When we send a GET request to the /dogs/:breed route, Nock intercepts the call to the Dog API and returns the custom response we saved in a file. We can change the output of the response appropriately to use for different test cases.

当我们向/dogs/:breed路由发送GET请求时,Nock截获对Dog API的调用,并返回我们保存在文件中的自定义响应。 我们可以适当地更改响应的输出以用于不同的测试用例。

结论 (Conclusion)

In today’s tutorial, we discussed integration testing and when to apply integration testing, and two of the common but advanced testing practices: stubbing and mocking. With that, our two-part article series on “Testing in Node.js” concludes. We hope you enjoyed the tutorials and gained at least the basic idea of how to write test cases for your program.

在今天的教程中,我们讨论了集成测试以及何时应用集成测试,以及两种常见但高级的测试实践:存根和模拟。 到此,我们分两部分的系列文章“在Node.js中进行测试”结束了。 我们希望您喜欢这些教程,并且至少了解了如何为程序编写测试用例的基本思想。

Thanks for reading!

谢谢阅读!

翻译自: https://medium.com/better-programming/testing-in-node-js-using-mocha-and-chai-part-2-5b5c56bf2075

node mocha

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
tcp ip upper tester 1.2 Testability Protocol and Service Primitives 1 Introduction and Functional Overview ................................................................. 5 2 Acronyms and Abbreviations............................................................................... 6 3 Related Documentation....................................................................................... 7 3.1 Input documents........................................................................................... 7 3.2 Related Standards and Norms ..................................................................... 7 3.3 Related specification .................................................................................... 7 4 Constraints and Assumptions.............................................................................. 8 4.1 Limitations .................................................................................................... 8 4.2 Applicability to car domains.......................................................................... 8 5 Intended context and applicability of protocol...................................................... 9 5.1 Dependencies to other protocol layers ......................................................... 9 5.2 Dependencies to other standards and norms............................................... 9 6 Protocol Specification........................................................................................ 10 6.1 Message Format and Protocol Fields......................................................... 10 6.2 Message Exchange.................................................................................... 11 6.3 States of Service Primitives........................................................................ 12 6.4 Default Behavior......................................................................................... 12 6.5 Constraints ................................................................................................. 12 6.6 Extensibility ................................................................................................ 12 6.7 Data Types and Format.............................................................................. 13 6.7.1 Boolean............................................................................................... 13 6.7.2 Unsigned............................................................................................. 13 6.7.3 Signed................................................................................................. 13 6.7.4 Floating Point ...................................................................................... 13 6.7.5 Variable Length................................................................................... 14 6.8 Result IDs................................................................................................... 15 6.8.1 Standard Results................................................................................. 15 6.8.2 Testability Specific .............................................................................. 15 6.8.3 Service Primitive Specific.................................................................... 15 6.9 Service Groups........................................................................................... 16 6.9.1 General Group .................................................................................... 16 6.9.2 UDP Group.......................................................................................... 17 6.9.3 TCP Group.......................................................................................... 17 6.10 Service Primitives....................................................................................... 18 6.10.1 Get Version ......................................................................................... 18 6.10.2 Start Test............................................................................................. 19 6.10.3 End Test.............................................................................................. 19 6.10.4 Close Socket....................................................................................... 20Testability Protocol and Service Primitives AUTOSAR TC Release 1.1.0 4 of 29 Document ID 778: AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives - AUTOSAR Confidential - 6.10.5 Create and Bind .................................................................................. 20 6.10.6 Send Data ........................................................................................... 21 6.10.7 Receive and Forward .......................................................................... 22 6.10.8 Listen and Accept................................................................................ 23 6.10.9 Connect............................................................................................... 23 6.10.10 Configure Socket ..........

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值