wip-1.6

1.6 Summary

1.6 总结

• Code tends to deteriorate. Each time you change something in a code base, the amount of disorder in it, or entropy, increases. Without proper care, such as constant cleaning and refactoring, the system becomes increasingly complex and disorganized. Tests help overturn this tendency. They act as a safety net—a tool that provides insurance against the vast majority of regressions.
  代码倾向于劣化。每当你修改代码库中的某些内容，其中的混乱程度，也就是熵，就会增加。如果缺少适当照料，例如持续清理和重构，系统会变得越来越复杂、越来越无序。测试有助于扭转这种趋势。它们像一张安全网，是一种为绝大多数回归问题提供保险的工具。
• It’s important to write unit tests. It’s equally important to write good unit tests. The end result for projects with bad tests or no tests is the same: either stagnation or a lot of regressions with every new release.
  编写单元测试很重要。编写好的单元测试同样重要。对于拥有坏测试或没有测试的项目，最终结果是一样的：要么停滞不前，要么每次新发布都伴随大量回归。
• The goal of unit testing is to enable sustainable growth of the software project. A good unit test suite helps avoid the stagnation phase and maintain the development pace over time. With such a suite, you’re confident that your changes won’t lead to regressions. This, in turn, makes it easier to refactor the code or add new features.
  单元测试的目标是让软件项目能够可持续增长。好的单元测试套件有助于避免停滞阶段，并长期维持开发节奏。有了这样的测试套件，你会更有信心相信自己的修改不会导致回归。这反过来会让重构代码或添加新功能变得更容易。
• All tests are not created equal. Each test has a cost and a benefit component, and you need to carefully weigh one against the other. Keep only tests of positive net value in the suite, and get rid of all others. Both the application code and the test code are liabilities, not assets.
  并非所有测试都生来平等。每个测试都有成本和收益两个组成部分，你需要仔细权衡二者。测试套件中只保留净价值为正的测试，删除所有其他测试。应用代码和测试代码都是负债，不是资产。
• The ability to unit test code is a good litmus test, but it only works in one direction. It’s a good negative indicator (if you can’t unit test the code, it’s of poor quality) but a bad positive one (the ability to unit test the code doesn’t guarantee its quality).
  代码是否能够被单元测试，是一个不错的试金石，但它只在一个方向上有效。它是好的负向指标（如果你无法对代码做单元测试，说明代码质量差），却是差的正向指标（能够被单元测试并不能保证代码质量）。
• Likewise, coverage metrics are a good negative indicator but a bad positive one. Low coverage numbers are a certain sign of trouble, but a high coverage number doesn’t automatically mean your test suite is of high quality.
  同样，覆盖率指标是好的负向指标，却是差的正向指标。低覆盖率数字明确表示存在问题，但高覆盖率数字并不自动意味着你的测试套件质量高。
• Branch coverage provides better insight into the completeness of the test suite but still can’t indicate whether the suite is good enough. It doesn’t take into account the presence of assertions, and it can’t account for code paths in third-party libraries that your code base uses.
  分支覆盖率能更好地洞察测试套件的完整性，但仍不能说明测试套件是否足够好。它不会考虑断言是否存在，也无法考虑代码库使用的第三方库中的代码路径。
• Imposing a particular coverage number creates a perverse incentive. It’s good to have a high level of coverage in core parts of your system, but it’s bad to make this high level a requirement.
  强制某个特定覆盖率数字会制造扭曲激励。在系统核心部分拥有高覆盖率是好事，但把这种高覆盖率设为强制要求则是坏事。
• A successful test suite is integrated into the development cycle, targets only the most important parts of your code base, and provides maximum value with minimum maintenance costs.
  成功的测试套件会集成到开发周期中，只针对代码库中最重要的部分，并以最低维护成本提供最大价值。
• The only way to achieve the goal of unit testing—that is, enabling sustainable project growth—is to learn how to differentiate between a good and a bad test, and to be able to refactor a test to make it more valuable.
  达成单元测试目标，也就是让项目能够可持续增长，唯一方式是学会区分好测试和坏测试，并且能够重构测试，让它变得更有价值。