许多人给我发消息，对从哪里开始测试感到困惑。 就像软件中的其他一切一样，我们努力构建抽象来简化我们的工作。 但这种抽象程度会随着时间的推移而发展，直到只有最初构建抽象的人才真正理解它。 其他所有人都只能按字面意思接受这些术语、API 和工具，并努力让事情正常工作。
我相信代码抽象的一点是，抽象 不是 魔法——它是代码。 我相信代码抽象的另一点是，它更容易通过实践来学习。
想象一下，一个经验不足的工程师向你寻求帮助。 他们渴望学习，他们希望对自己的代码充满信心，他们准备开始测试。 👍 他们总是准备好向你学习，他们已经写下了一份他们希望你为他们定义的术语、API 和概念清单
- 断言
- 测试框架
describe/it/beforeEach/afterEach/test函数- 模拟/存根/测试替身/间谍
- 单元/集成/端到端/功能/可访问性/验收/手动测试
所以…
你能为这位萌芽的工程师说出这些定义吗？ 你能解释断言库和测试框架之间的区别吗？ 或者，对你来说，它们更容易 识别 而不是 解释 吗？
重点是，你对这些术语和抽象理解得越好，你就能越有效地教它们。 而且，如果你能教它们，你也能更有效地使用它们。
进入教工程师钓鱼的时刻。 你知道你可以 自己编写 断言库和测试框架吗？ 我们经常认为这些抽象超出了我们的能力，但事实并非如此。 每个流行的断言库和框架都从一行代码开始，然后是另一行，再是另一行。 你不需要任何工具来编写简单的测试。
这是一个示例
const {sum} = require('../math')
const result = sum(3, 7)
const expected = 10
if (result !== expected) {
throw new Error(`${result} is not equal to ${expected}`)
}把它放到名为 test.js 的模块中，并使用 node test.js 运行它，然后，砰，你就可以开始确信 math.js 模块中的 sum 函数按预期工作。 让它在 CI 上运行，你就可以确信它不会随着代码库的更改而崩溃。 🏆
让我们看看失败会是什么样子
所以，看来我们的 sum 函数是减而不是加，我们已经能够通过这个脚本自动检测到这一点。 我们现在需要做的就是修复 sum 函数，再次运行我们的测试脚本，然后
太棒了！ 脚本在没有错误的情况下退出，所以我们知道 sum 函数正常工作。 这就是测试框架的本质。 它还有很多其他内容（例如，更友好的错误消息、更好的断言等），但这是一个理解基础的好起点。
一旦你从根本上理解了抽象的工作原理，你可能就想使用它们，因为，嘿，你刚刚学会了钓鱼，现在你可以去钓鱼了。 我们有一些非常棒的钓鱼杆，呃，工具可供使用。 我最喜欢的是 Jest 测试平台。 它功能强大、功能齐全，并允许我编写测试，让我对在更改代码时不会破坏任何东西充满信心。
我觉得基础知识非常重要，所以在 TestingJavaScript.com 上，我包含了一个关于它的完整模块。 这是你可以学习测试任何 JavaScript 应用程序的智能、高效方式的地方。 我对为你们创造的东西感到非常高兴。 我认为它将通过让你有机会从头开始实现部分内容来帮助你加速对测试工具和抽象的理解。 （希望）结果？ 你可以开始编写可维护的测试，并旨在日复一日地对你的代码充满信心。 🎣
早鸟优惠正在进行中！ 所有层级均享 40% 折扣！ 优惠将在未来几天内结束，因此请 尽快抓住这个机会！
