不幸的是，测试在许多组织中仍然没有得到应有的关注。有时，如果开发人员没有编写任何测试，他们会感到内疚，同时测试代码往往没有得到适当的审查。相反，评论中经常检查的唯一事情是是否有任何测试，这是一种耻辱，因为仅仅进行测试还不够好。实际上，它们至少应该与项目中的所有其他代码具有相同的质量，即使不是更高的质量。否则，测试确实可能会阻碍你，因为测试失败的次数太多，难以理解，或者运行时间太长。我已经在关于使用内存中实现而不是存储库模拟的博客文章中讨论了其中的一些要点。现在我想讨论一些其他的、更一般的、我在编写测试时要注意的事情。
极简主义是关键
stack overflow 要求您为问题添加最少的、可重现的示例，在我看来，这对于出于完全相同的原因编写测试也是非常好的建议。特别是在编写测试几个月后阅读测试时，如果发生的事情较少，就更容易完全理解正在发生的事情。因此只编写测试绝对必要的代码，并抵制仅仅因为这样做很容易就添加更多内容的诱惑。但测试代码当然仍然必须完整，即测试应包含尽可能多的行，但尽可能少。
追求 100% 的代码覆盖率
这可能是一个不受欢迎的观点，但我认为以 100% 代码覆盖率为目标是完全有意义的，尽管许多人似乎认为这是一种不好的做法。
有时团队会选择较低的值，例如代码覆盖率达到 90%。然而，这对我来说没有多大意义。首先，所有这些数字都有些随意，并且很难使用数据进行备份。此外，在编写新代码时，并非所有代码都需要经过测试才能通过该阈值。如果有人设法提高覆盖率，那么下一个人可能根本不编写任何测试，同时仍然保持高于 90% 的代码覆盖率，这会导致错误的自信感。
我经常听到的借口之一是为 getter 和 setter 等简单函数编写测试没有意义。也许令人惊讶的是，我完全同意这一点。但这里有一个问题：如果没有一个测试真正使用这些 getter 和 setter，那么可能就没有必要使用它们。因此，与其抱怨实现 100% 测试覆盖率有多么困难，最好不要首先编写不需要的代码。这也避免了每行代码带来的维护负担。
但是，有一个小问题：有时代码会执行奇怪的操作，这可能会导致代码覆盖工具将某些行标记为未覆盖，即使它是在测试运行期间执行的。我没有经常遇到这样的情况，但如果没有办法使这项工作正常进行，我会将它们排除在代码覆盖范围之外。例如。 phpunit 允许使用他们的 codecoverageignore 注释来做到这一点：
<?php class someclass { /** * @codecoverageignore */ public function dosomethingnotdetectedascovered() { } }
这样这个函数就不会被包含在代码覆盖率分析中，这意味着仍然有可能达到 100% 的代码覆盖率，并且我也会不断检查该值。另一种方法是选择低于 100% 的值，但这样会出现上面提到的相同问题：其他代码也可能不会被测试覆盖，并且可能会被遗漏。
话虽如此，100% 的代码覆盖率当然不能保证您的代码没有任何错误。但是，如果您的应用程序代码中确实有未覆盖的行，您甚至不会对测试进行更改以发现该行中的潜在错误。
写出好的断言
编写测试的原因是我们想要断言代码的某种行为。因此断言是测试中非常重要的一部分。
当然，编写断言时最重要的考虑因素是它正确地测试代码的行为。但紧随其后的是代码失败时断言的行为方式。如果断言由于某种原因失败，那么问题对于开发人员来说应该尽可能明显。在此 symfony 拉取请求中当前正在处理的情况就是这种情况显而易见的情况。 symfony 附带了一个assertresponsestatuscodesame 方法，它允许在功能测试中检查响应的状态代码：
<?php declare(strict_types=1); class logincontrollertest extends webtestcase { public function testformattributes(): void { $client = static::createclient(); $client->request('get', '/login'); $this->assertresponsestatuscodesame(200); $this->assertselectorcount(1, 'input[name="email"][required]'); } }
这个测试的问题是它在状态码不是 200 的情况下生成的输出。由于测试通常在开发环境中运行，symfony 在访问这个 url 时会返回一个错误页面，assertresponsestatuscodesame 方法会输出断言失败时的完整响应。这个输出非常长，因为它不仅返回 html，还返回 css 和 JavaScript，而且我的回滚缓冲区实际上太小，无法让我阅读整个消息。
这绝对是我迄今为止遇到的最糟糕的例子，但如果代码中使用了错误的断言，它也会很烦人。让我们看一下上面的assertselectorcount断言的输出，如果给定的选择器没有恰好产生一个元素，则该断言会失败并显示以下消息：
failed asserting that the crawler selector "input[name="email"][required]" was expected to be found 1 time(s) but was found 0 time(s).
它很好地了解了发生的问题。但是，断言也可以用不同的方式编写（不要在家里这样做！）：
$this->asserttrue($client->getcrawler()->filter('input[name="email"][required]')->count() === 1);
有人可能会说这完全一样，因此使用哪种变体并不重要。这与事实相差甚远，因为如果电子邮件没有单个必填输入字段，则会出现以下消息：
failed asserting that false is true.
这根本没有帮助，无论谁致力于解决问题，首先都必须弄清楚问题到底是什么。这表明，始终应该使用合适的断言，并且 phpunit 附带了许多适合所有类型用例的断言。有时创建自定义断言甚至是有意义的。
近年来我看到越来越流行的一个相对较新的断言是快照测试。尤其是当开始从事前端项目时，它似乎有很大帮助。我过去经常将它与 react 一起使用。主要要点是您的测试看起来像这样：
import renderer from 'react-test-renderer'; import Component from '../Component'; it('renders correctly', () => { const tree = renderer .create(<Component />) .toJSON() ; expect(tree).toMatchSnapshot(); });
神奇的事情发生在 tomatchsnapshot 方法中。在第一次运行时，它将树变量的内容写入单独的文件中。在后续运行中，它将树值的新值与之前存储在单独文件中的值进行比较。如果某些内容发生更改，它将导致测试失败并显示差异，并可以选择再次更新快照，这意味着您可以立即修复测试。
虽然这听起来确实不错，但它也有一些缺点。首先，快照非常脆弱，因为每当组件的渲染标记发生更改时，测试就会失败。其次，测试的意图是隐藏的，因为它没有解释作者真正想要测试的内容。
但是，我真正喜欢它的是，每当我更改组件时，它都会提醒我使用该组件的所有其他组件，因为所有这些快照在下次运行时都会失败。出于这个原因，我喜欢每个组件至少进行一次快照测试。
结论
总而言之，我认为您可以立即开始做一些事情来提高测试质量：
- 将测试中的代码保持在绝对需要的最低限度
- 目标是 100% 的代码覆盖率，如果无法测试，请正确地将代码从代码覆盖率机制中排除
- 当测试失败时，使用正确的断言可以获得更好的错误消息
在我看来，遵循这几条规则已经会产生巨大的影响，并帮助您长期享受在代码库中工作的乐趣！
