For the complete documentation index, see llms.txt. This page is also available as Markdown.

测试服务(已弃用)

服务应主要通过以下方式进行测试 API 测试,也就是说,一组通过 API 运行服务代码的测试,启动服务时将其外部依赖项进行模拟(数据库和 API)。 单元测试 应在以下情况下包含:当发现代码中有大量用例需要覆盖的工具性部分,或存在性能较差的代码,使其无法或难以通过 API 测试来测试。这样做的原因是,由于我们的微服务架构会减少职责,从而减少需要测试的代码量,服务逻辑较为简单,因此在确保服务正常工作时,API 测试是最具时间价值比的选择。

测试栈

服务必须使用以下工具进行测试 Jest 作为主要测试框架,并使用 supertest 作为搭建服务器并对其进行测试的框架。

目录结构

由于服务可能同时拥有 API 测试和单元测试,因此测试会放在不止一个位置:

  • 单元测试必须与它们所测试的文件或模块放在一起,名称相同,但扩展名为 spec.ts 而不是 ts.

  • API 测试会覆盖服务中的各个代码路径,因此它们必须放在根路径下的 test 目录中。文件将以它们所测试的服务资源命名,也就是说,如果 API 测试要测试资源 books,通常位于 /books,那么文件名必须是 books.spec.ts 并且必须放在 test 目录中。

测试内容

  • 应用于路由的中间件(认证等),以确保路由按预期工作。

  • 控制器逻辑,以确保路由执行我们期望的操作。

API 测试服务

如前所述,API 测试将使用 Jest 和 supertest 完成。

为了说明开发者如何进行 API 测试,我们有以下示例:

在这个示例中,我们看到一个路由使用了不同的 HTTP 方法:GET 和 POST。两个端点都指向同一个资源 books,因此必须在 books.spec.ts 下创建一个名为 test 的文件夹来存放它们的测试。

所有路由以及不同的执行流程都必须被彻底测试。开发者必须为这些端点测试以下情况:

  • 请求所有书籍能够正常工作,返回 200 和所有书籍列表。

  • 请求某个作者的所有书籍能够正常工作,返回 200 和该作者的所有书籍列表。

  • 未认证地提交一本书会失败,返回 401 和错误消息。

  • 已认证地提交一本书能够正常工作,返回 200 并插入该书。

这些情况肯定会有它们的 it,而这些 it 的期望至少必须包含 预期的响应状态 以及 响应体中的预期内容 (如果有的话)。

这些端点测试应按如下方式编写:

最后更新于