wip-2.5

2.5 Summary

2.5 总结

• Throughout this chapter, I’ve refined the definition of a unit test: a unit test verifies a single unit of behavior, does it quickly, and does it in isolation from other tests.
  在本章中，我逐步细化了单元测试的定义：单元测试验证单个行为单元，运行快速，并且与其他测试隔离运行。
• The isolation issue is disputed the most. The dispute led to the formation of two schools of unit testing: the classical (Detroit) school, and the London (mockist) school. This difference of opinion affects the view of what constitutes a unit and the treatment of the system under test’s dependencies.
  隔离问题争议最大。这种争议导致了两个单元测试学派的形成：经典（底特律）学派和伦敦（mockist）学派。这种意见差异会影响对“什么构成一个单元”的看法，以及对被测系统依赖的处理方式。
• The London school states that the units under test should be isolated from each other. A unit under test is a unit of code, usually a class. All of its dependencies, except immutable dependencies, should be replaced with test doubles in tests.
  伦敦学派认为，被测单元应该彼此隔离。被测单元是代码单元，通常是一个类。除了不可变依赖之外，它的所有依赖都应该在测试中用测试替身替换。
• The classical school states that the unit tests need to be isolated from each other, not units. Also, a unit under test is a unit of behavior, not a unit of code. Thus, only shared dependencies should be replaced with test doubles. Shared dependencies are dependencies that provide means for tests to affect each other’s execution flow.
  经典学派认为，需要彼此隔离的是单元测试，而不是单元。此外，被测单元是行为单元，而不是代码单元。因此，只有共享依赖应该用测试替身替换。共享依赖是为测试影响彼此执行流程提供手段的依赖。
• The London school provides the benefits of better granularity, the ease of testing large graphs of interconnected classes, and the ease of finding which functionality contains a bug after a test failure.
  伦敦学派提供的好处包括更好的粒度、更容易测试大型互联类图，以及在测试失败后更容易找到哪个功能包含缺陷。
• The benefits of the London school look appealing at first. However, they introduce several issues. First, the focus on classes under test is misplaced: tests should verify units of behavior, not units of code. Furthermore, the inability to unit test a piece of code is a strong sign of a problem with the code design. The use of test doubles doesn’t fix this problem, but rather only hides it.
  伦敦学派的好处一开始看起来很有吸引力。然而，它们也引入了几个问题。首先，对被测类的关注放错了位置：测试应该验证行为单元，而不是代码单元。此外，无法对一段代码进行单元测试，是代码设计存在问题的强烈信号。使用测试替身并不会修复这个问题，而只是隐藏它。
• While the ease of determining which functionality contains a bug after a test failure is helpful, it’s not that big a deal because you often know what caused the bug anyway—it’s what you edited last.
  虽然测试失败后更容易确定哪个功能包含缺陷是有帮助的，但这并不是大问题，因为你通常已经知道是什么造成了缺陷——就是你最后编辑的内容。
• The biggest issue with the London school of unit testing is the problem of over-specification—coupling tests to the SUT’s implementation details.
  伦敦单元测试学派最大的问题是过度指定，也就是把测试耦合到 SUT 的实现细节。
• An integration test is a test that doesn’t meet at least one of the criteria for a unit test. End-to-end tests are a subset of integration tests; they verify the system from the end user’s point of view. End-to-end tests reach out directly to all or almost all out-of-process dependencies your application works with.
  集成测试是至少不满足单元测试某一项标准的测试。端到端测试是集成测试的子集；它们从最终用户视角验证系统。端到端测试会直接触达应用使用的所有或几乎所有进程外依赖。
• For a canonical book about the classical style, I recommend Kent Beck’s Test-Driven Development: By Example. For more on the London style, see Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce. For further reading about working with dependencies, I recommend Dependency Injection: Principles, Practices, Patterns by Steven van Deursen and Mark Seemann.
  关于经典风格的经典书籍，我推荐 Kent Beck 的《Test-Driven Development: By Example》。关于伦敦风格，参见 Steve Freeman 和 Nat Pryce 的《Growing Object-Oriented Software, Guided by Tests》。关于依赖处理的进一步阅读，我推荐 Steven van Deursen 和 Mark Seemann 的《Dependency Injection: Principles, Practices, Patterns》。