作为测试的专门倡导者，我一直在寻找创新的方法和技术，以增强对我的编码实践的信心。每当出现新的测试解决方案时，我都热切地深入研究它，渴望评估其潜在收益。这种无限的好奇心使我探索了Nodejs本身的相对新鲜产品：它自己的测试跑步者。
nodejs现在提供自己的测试跑步者，这对寻求可靠测试框架的开发人员拥有巨大的希望。我的潜力很感兴趣，我开始了一次旅程，检查了这种新工具是否真正准备好生产并可以依靠。
建立“ REDERINSS”的标准
确定新的Nodejs测试跑者是否真的是“ Dev Ready”，我首先定义了自己的一组标准。这些标准可以在五个关键方面进行总结：
- 测试执行：测试套件如何运行？与现有框架相比，是否存在任何结构差异？
- 反馈机制：跑步者如何有效地对测试结果提供反馈？
- 观察者功能：为了促进测试驱动的开发（TDD）实践，或仅仅是为了监视相关文件更改，跑步者是否包括可靠的文件观察器？
- 断言能力：跑步者的主张如何？有强大断言测试的内置功能吗？
- 代码覆盖范围：使用不熟悉的代码时，我经常依靠测试覆盖范围报告来评估我在进行修改时可以拥有的信心水平。节点跑步者可以生成全面的覆盖报告吗？
通过彻底检查这五个方面，我旨在获得必要的信心，将这个新的测试跑步者整合到我的项目中。
准备将Nodejs投入测试，看看它如何满足这些标准？让我们潜入并找出！
嘿！有关您将要阅读的内容的更多内容，请在Twitter上查看@mattibarzeev ð»
这篇文章中提到的代码可以在我的node-testing-lab GitHub repo中找到。
Nodejs测试跑者在第20版中达到了稳定性，尽管它甚至在此之前就可以使用。
现在，让我们从一开始就开始吧？最初的步骤涉及创建一个全新的空项目，在其中配置纱线，并确保使用Nodejs版本20。为此，我使用nvm，该工具可以使不同的Nodejs版本的安装和管理。这就是我的方式：
nvm install v20.0.0
并确保我使用它：
nvm use v20.0.0
很酷，我们很高兴去。
测试执行
我将使用TDD方法创建一个简单的添加函数，让我们看看它是如何进行的 -
我计划创建的服务位于一个名为calc-service.js的文件上，我还有另一个用于calc-service.test.js的测试文件，在此阶段都是空的。
注意：在此阶段，我们不使用Babel，因此为了使节点能够与ESM Itmorts合作，我们应该将项目类型声明为“模块”。这是在
中完成的package.json file
现在，让我们从简单的检查开始，以确保我的跑步者实际上在工作。尚无断言：
import {describe, it} from 'node:test';
describe('calc-service', () => {
it('should work...', () => {});
});
由于我想保留我熟悉的相同测试范式，因此我正在进口，并且类似于玩笑测试。
对于运行测试，我简单地在终端中键入此命令：
node --test
我得到了这个输出，这有点丑陋，但至少我们可以看到我们在哪里：
TAP version 13
# Subtest: /home/matti/my/labs/node-testing-react/src/services/calc-service.test.js
ok 1 - /home/matti/my/labs/node-testing-react/src/services/calc-service.test.js
---
duration_ms: 59.507962
...
1..1
# tests 1
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0
# duration_ms 63.401323
标准：测试套件如何运行？与现有框架相比，是否有结构上的差异？
答案：测试套件以简单的终端命令运行，而开玩笑或摩卡咖啡测试没有结构上的差异。
反馈机制
由于很难理解TAP报告格式，让我们切换到一个更具吸引力且容易获得的选项，称为“ Spec”记者。为了实现这一目标，我在package.json文件中包含一个脚本，该文件指定了所需的记者。从现在开始，我将在终端中使用以下命令来运行测试：
"scripts": {
"test": "node --test --test-reporter spec"
}
，结果看起来像这样：
ahhâ€好多了。我有颜色，我可以看到我的测试通过了需要多长时间的迹象。膨胀。
标准：跑步者如何有效地提供测试结果的反馈？
答案：这足够好，我们会看到我们需要的细节，如果测试失败，我们会得到相关线的指示。也许太冗长了，但这还可以。
观察者功能
在对我们刚刚创建的代码进行任何更改之前，必须从测试中持续反馈。为此，我们需要一种监视测试文件及其所有关联文件的手表机制，每当修改这些文件中的任何一个时，都会触发测试运行。
要实现此功能，我创建了一个NPM脚本，该脚本观察SRC目录中的所有测试文件。这是我开发的脚本：
"test:watch": "node --test --test-reporter spec --watch ./src/**/*.test.js"
注意：手表参数必须具有一个文件路径值，否则它将不起作用。
标准：为了促进测试驱动的开发（TDD）实践，或仅仅是为了监视相关文件更改，跑步者是否包括可靠的文件观察者？
答案：是的：）
好吧，现在我们有持续的反馈，我们可以从一些断言开始。
断言能力
我从测试添加方法开始，添加1和2，希望结果为3。这是测试：
import {describe, it} from 'node:test';
import assert from 'node:assert';
import {add} from './calc-service.js';
describe('calc-service', () => {
it('should return a result of adding 2 numbers', () => {
const result = add(1, 2);
assert.equal(result, 3);
});
});
主张是从节点导入的：sostert模块，该模块提供了various types of assertions。
正如预期的那样，初始测试会立即失败，促使我们解决问题。但是，在这种情况下，我不会严格遵守测试驱动的开发（TDD）原则，仅实现通过测试所需的最低限度（如果您对此感兴趣，您可以探索我写过的其他帖子，例如“ Creating a React Component with TDD”或“ Creating a React Custom Hook using TDD”等）
测试通过，如果我可以添加，则可以快速。
标准：跑步者的主张如何？是否有内置的功能用于强大的断言测试？
答案：当然看起来像。有许多断言类型似乎支持高级测试用例。
代码覆盖范围
是什么使代码覆盖范围很大？好吧，这不仅仅是给您的经理以很高的比例打动您的经理。代码覆盖范围非常重要，因为它为代码重构的安全提供了重要的见解。尽管它不能保证绝对确定性，但是在对代码进行修改时，拥有广泛的代码覆盖范围会带来更大的信心感。这就是为什么必须能够可视化和分析您的代码覆盖范围的原因。
JEST通过利用伊斯坦布尔/纽约市生成全面报告，提供了方便的覆盖范围解决方案，其中包括逐线代码覆盖范围的详细信息，并突出显示缺乏覆盖范围的任何领域。同样，我渴望对Nodejs测试跑者具有类似的功能。
有趣的是，Nodejs本身提供内置的覆盖范围支持。通过定义node_v8_coverage环境变量并指定目标目录，NodeJS生成了V8覆盖范围数据。但是，这仅仅是第一步，因为我们旨在将这些数据转换为更具吸引力的格式，该格式很容易被人类理解。
幸运的是，存在一个helpful package called "c8"，为我们简化了整个过程。它需要设置NODE_V8_COVERAGE环境变量并转换覆盖范围数据，直接在您的终端中生成全面的文本报告。
要将“ C8”软件包合并到项目中，我将其安装，然后将以下脚本添加到package.json文件：
"test:coverage": "c8 node --test"
运行后，我将其在终端中得到：
这真的很好，但是我希望有所有细节的凉爽的HTML覆盖范围报告。
再次证明“ C8”是可靠的，并允许我们将记者设置为“ HTML”。虽然可以直接在NPM脚本中指定记者，但我更喜欢为“ C8”创建一个单独的配置文件，因为它可以从长远来看更轻松地维护。
介绍.c8rc.json配置文件，该文件现在包括两个记者（以满足我对命令行和HTML报告中文本报告的需求）。这是配置文件：
{
"reporter": ["text", "html"]
}
这是我们得到的不错的HTML结果，就像我们习惯了：
标准：节点跑步者可以生成全面的报道报告吗？
答案：是的！
包起来
总而言之，很明显，NodeJS通过提供一个可靠的测试跑步者可以处理基本的测试任务而不依赖于Jest或Mocha（例如Jest或Mocha），从而超过了期望。强调在第三方依赖性上使用本地特征的利用会产生更好的结果。
是准备好了吗？我不得不说 - 是的，我相信这是。
但是，仍然没有探索的方面。一个这样的方面就是嘲笑，根据documentation，这似乎具有有希望的方法，但需要进一步调查。
此外，我们如何处理需要转滤的测试代码，例如React？尽管Jest为此目的提供了变压器，但问题仍然是是否可以将类似的功能集成到Nodejs生态系统中。
这些未解决的问题为思想提供了食物，鼓励我们更深入地研究Nodejs提出的可能性。在此之前，让我们继续我们的探索，并继续在这个动态环境中突破测试的界限。请继续关注以后的文章中的更多见解：）
这篇文章中提到的代码可以在我的node-testing-lab GitHub repo中找到。
嘿！有关您刚刚阅读的内容的更多内容，请在Twitter上查看@mattibarzeev ð»