29、单元测试的最佳实践与策略

单元测试的最佳实践与策略

1. 避免功能更改与重构混合

在对代码库进行更改时，通常最好要么进行功能更改，要么进行重构，而不要同时进行两者。重构不应改变任何行为，而功能更改则应该改变。如果同时进行功能更改和重构，就很难判断哪些行为变化是功能更改所预期的，哪些可能是重构中出现的错误导致的。通常更好的做法是先进行重构，然后再单独进行功能更改，这样更容易找出潜在问题的原因。

代码经常需要重构，在成熟的代码库中，重构的工作量往往超过编写新代码的工作量。因此，确保代码在重构时不会出错至关重要。通过使测试与实现细节无关，我们可以确保有一个可靠且清晰的信号，让任何重构代码的人都能据此判断自己是否犯了错误。

2. 清晰解释的测试失败信息

测试的主要目的之一是防止未来的代码损坏。常见的情况是，另一位工程师进行的更改无意中破坏了他人的代码，测试开始失败，从而提醒工程师他们破坏了某些东西。工程师随后会查看测试失败信息以找出问题所在。如果测试失败信息没有明确指出哪里出了问题，而工程师又对无意中破坏的代码不太熟悉，那么他们可能会浪费大量时间来排查问题。

为了确保测试能清晰准确地解释哪里出了问题，需要考虑测试在出现问题时会产生什么样的失败信息，以及这些信息对其他工程师是否有用。例如，当测试失败时，可能会看到两种不同的失败信息：一种只是表明获取事件有问题，但没有提供具体问题的信息；另一种则清晰地描述了问题，如事件没有按时间顺序返回。

确保测试失败信息清晰解释问题的最佳方法之一是一次只测试一件事，并为每个测试用例使用描述性的名称。这样通常会产生许多小的测试用例，每个测试用例锁定一个特定的行为，而不是一个试图一次性测试所有内容的大测试用例。当测试失败时