越来越多的人向我询问测试资源，所以让我把我写的所有内容都放在一篇文章里。请收藏、分享，最重要的是，请阅读这些文章。

• 测试的真正目的 https://epicweb.dev/the-true-purpose-of-testing… 开发人员经常忽视基本原理，在没有充分理解测试是什么以及它的功能是什么的情况下，匆忙编写测试。测试本身并不因为它的存在而固有地有用。阅读这篇文章，了解什么使测试变得有用。
• 断言的黄金法则 https://epicweb.dev/the-golden-rule-of-assertions… 关于什么构成一个好的测试，有很多争论。在这篇文章中，我定义了一种简短且客观的方法来评估测试的质量，无论使用何种语言或测试系统。毫不夸张地说，这将彻底改变你对待测试的方式。
• 测试的解剖结构 https://epicweb.dev/anatomy-of-a-test… 让我们谈谈构成任何自动化测试的构建块。从 JavaScript 到 Go 和 Rust——这些构建块驱动着各地的测试。了解你的构建块。
• 隐式断言 https://epicweb.dev/implicit-assertions… 你知道有一种方法可以在测试中表达期望而不必写 “expect” 吗？这些被称为隐式断言，它们非常强大，因为它们帮助你通过写更少的代码来表达更多的内容。
• 逆断言 https://epicweb.dev/inverse-assertions… 有时你需要断言某事没有发生。这可能会很棘手，特别是如果那件事是异步的。你最不想看到的是假阳性。你实际需要的是逆断言。
• 利用代码覆盖率 https://epicweb.dev/making-use-of-code-coverage… 代码覆盖率一直是工程界争论的话题。测试中 100% 的代码覆盖率是好是坏？什么时候应该追求它？为什么有人说它有害？我在本文中回答了所有这些疑问，并提供了关于何时使用（和不使用）代码覆盖率的实用建议。
• 好代码，可测试的代码 https://epicweb.dev/good-code-testable-code… 到目前为止，你已经意识到有些代码比其他的更容易测试。但为什么？让我们来看看代码可测试性的特征，它由什么定义，它与复杂性的关系是什么，以及如何使你的代码更具可测试性。
• 什么是测试边界？ https://epicweb.dev/what-is-a-test-boundary… 自动化测试很少涉及你的整个系统（是的，即使是端到端测试也有例外）。通常会有一个你划定界限的地方。这个边界。了解它是什么，以及如何高效地使用测试边界来专注于你想测试的确切行为。
• 聪明地对待不稳定的测试 https://epicweb.dev/be-smart-about-flaky-tests… 不稳定性是可靠性的噩梦。如果你之前写过测试，可能有过不稳定性的经历。但它的核心是什么，什么导致它？你该如何应对不稳定性？
• 编写会失败的测试 https://epicweb.dev/writing-tests-that-fail… 你编写测试是为了让它们失败。我们都喜欢绿色的 CI，但测试的真正价值在于它们失败的时候。重要的是它们何时以及如何失败。

测试的真正目的

来源: https://www.epicweb.dev/the-true-purpose-of-testing

让我问你一个问题：自动化测试的目的是什么？

无论你是否在过去写过测试，你很可能已经听说过测试可以很有用。我也知道你还听说过关于测试更多是负担和烦恼而非帮助的故事。坦白说，我认为双方都是对的！但为了理解为什么，我首先会告诉你一个秘密。

没有测试仅仅因为存在就固有地有用。当测试实现其目的时，它就变得有用。

那么，这个目的是什么呢？

顾名思义，自动化测试旨在帮助我们自动化某些事情。我们获取应用程序的特定状态，执行一些操作，并检查最终系统是否符合我们的预期。这就是任何测试所做的，然而有些测试比其他测试更有用。有且仅有一件事定义并控制这种差异。

意图

正如每一段代码都有其存在的原因一样，每一个测试都存在以验证该代码背后的意图。

当用户访问页面时，段落会被渲染；当用户点击按钮时，会发出请求；当调用函数时，会返回正确的数据——我们想让计算机做的事情数不胜数。然后我们使用计算机理解的编程语言来实现这些意图。

有时，意图和实现是相同的。看看这个简单的将两个数字相加的函数：

function sum(a, b) {
  return a + b
}

add 函数的意图是将任意给定的两个数字 a 和 b 相加。它的实现字面意义上就是这样做的：a + b。

然而，在现实世界中，我们的意图很少如此简单。我们通常编写数百行代码来实现某一特定功能。最终，系统的实现并不直接对应于其背后的意图。此时，在测试的背景下，意图和实现之间的区别变得至关重要。

测试的目的

测试的真正目的与每个测试用例背后的 意图 紧密相连，可以总结如下：

你编写测试是为了验证系统背后的意图。

只有当测试验证了意图时，它才会变得有用。

我见过拥有数百甚至数千个自动化测试的项目，但它们对任何东西都没有贡献。它们经常在拉取请求中失败。它们难以阅读且令人痛苦地难以导航。它们明天就可以被移除，而没有人会注意到。随着时间的推移，我逐渐意识到是什么导致了这种情况。

它们与被测试代码的意图无关。它们没有验证代码做了什么（意图），而是详细关注它是怎么做的（实现）。

“不要测试实现细节（https://kentcdodds.com/blog/testing-implementation-details）” 是自动化测试中常见的建议。听到并不意味着理解，理解并不意味着应用。我们花了太多时间编写代码，以至于经常对意图和实现之间的界限视而不见。最终，我们确实打算做出每一个程序选择，所以为什么不测试这些呢？

只有当你开始将实现细节视为达到目的的手段，并专注于手头更大的意图时，你才能释放自动化测试的价值。用户不知道你的应用程序功能是如何工作的，你的测试也不应该知道。用户关心的是，无论你的应用程序做出什么承诺，允许他们实现什么意图，它都能无误地完成。

当你不确定要测试什么时，切换到这种思维模式也会大有帮助。突然间，你可以以任何规模处理任何系统。有疑问时，测试意图。始终测试意图。

这就是自动化测试的目的。