程序员：前任留下的代码你要怎么处理？(2)

虽然这是乏味的，但它允许我们通过编写测试来学习，这是它的主要优点。假设代码现在可以正常工作，而我们需要编写测试，以便预期的输入会导致预期的输出。在我们完成这个测试的过程中，我们逐渐了解到代码的意图和功能。例如，给出以下代码
我们对代码的意图以及为什么在代码中使用Magic number知道得并不多，但是我们可以创建一组测试，已知输入产生已知输出。例如，通过做一些简单的数学和解决构成成功的阈值薪水问题，我们发现如果一个人的年龄在30岁以下，且每年大概赚68,330美元，那么他被认为是成功的（按照本规范的标准）。虽然我们不知道那些magic number是什么，但是我们知道它们确实减少了初始的薪水值。因此，68,330美元的阈值是扣除前的基本工资。通过使用这些信息，我们可以创建一些简单的测试，例如：
通过这三个测试，我们现在对现有代码的工作方式有了大致的了解：如果一个人不到30岁，且每年赚$ 68,300，那么他被认为是成功人士。虽然我们可以创建更多的测试来确保临界情况（例如空白年龄或工资）功能正常，但是一些简短的测试不仅使我们了解了原始功能，还给出了一套自动化测试，可用于确保在对现有代码进行更改时，我们不会破坏现有功能。
使用现有测试
如果有足够的代码测试组件，那么我们可以从测试中学到很多东西。正如我们创建测试一样，通过阅读测试，我们可以了解代码如何在功能层面上工作。此外，我们还可以知道原作者是如何让代码运行的。即使测试是由原作者以外的人（在我们接触之前）撰写的，也依然能够为我们提供关于其他人对代码的看法。
虽然现有的测试可以提供帮助，但我们仍然需要对此持保留态度。测试是否与代码的开发更改一起与时俱进是很难说的。如果是的话，那么这是一个很好的理解基础；如果不是，那么我们要小心不要被误导。例如，如果初始的工资阈值是每年75,000美元，而后来更改为我们的68,330美元，那么下面这个过时的测试可能会使我们误入歧途：
这个测试还是会通过的，但没有了预期的作用。通过的原因不是因为它正好是阈值，而是因为它超出了阈值。如果此测试组件包含这样一个测试用例：当薪水低于阈值1美元时，过滤器就返回false，这样第二个测试将会失败，表明阈值是错误的。如果套件没有这样的测试，那么陈旧的数据会很容易误导我们弄错代码的真正意图。当有疑问时，请相信代码：正如我们之前所表述的那样，求解阈值表明测试没有对准实际阈值。
另外，要查看代码和测试用例的存储库日志（即Git日志）：如果代码的最后更新日期比测试的最后更新日期更近（对代码进行了重大更改，例如更改阈值），则测试可能已经过时，应谨慎查看。注意，我们不应该完全忽视测试，因为它们也许仍然能为我们提供关于原作者（或最近撰写测试的开发人员）意图的一些文档，但它们可能包含过时或不正确的数据。