unit-testing-5.5-总结

Summary

总结

仅个人学习使用，支持正版。

书名：Unit Testing: Principles, Practices, and Patterns

• Test double is an overarching term that describes all kinds of non-production-ready, fake dependencies in tests. There are five variations of test doubles—dummy, stub, spy, mock, and fake—that can be grouped in just two types: mocks and stubs. Spies are functionally the same as mocks; dummies and fakes serve the same role as stubs.
  测试替身是一个总称，用来描述测试中各种非生产级的伪造依赖。测试替身有五种变体：dummy、stub、spy、mock 和 fake，它们可以归为两类：mock 和 stub。spy 在功能上与 mock 相同；dummy 和 fake 扮演与 stub 相同的角色。
• Mocks help emulate and examine outcoming interactions: calls from the SUT to its dependencies that change the state of those dependencies. Stubs help emulate incoming interactions: calls the SUT makes to its dependencies to get input data.
  mock 帮助模拟并检查向外交互：也就是 SUT 对其依赖发起、会改变这些依赖状态的调用。stub 帮助模拟向内交互：也就是 SUT 为获取输入数据而对依赖发起的调用。
• A mock (the tool) is a class from a mocking library that you can use to create a mock (the test double) or a stub.
  mock（工具）是 mocking 库中的类，你可以用它创建 mock（测试替身）或 stub。
• Asserting interactions with stubs leads to fragile tests. Such an interaction doesn’t correspond to the end result; it’s an intermediate step on the way to that result, an implementation detail.
  对 stub 的交互做断言会导致脆弱测试。这类交互并不对应最终结果；它只是通往最终结果的中间步骤，是实现细节。
• The command query separation (CQS) principle states that every method should be either a command or a query but not both. Test doubles that substitute commands are mocks. Test doubles that substitute queries are stubs.
  命令查询分离（CQS）原则认为，每个方法要么是命令，要么是查询，但不能两者都是。替代命令的测试替身是 mock；替代查询的测试替身是 stub。
• All production code can be categorized along two dimensions: public API versus private API, and observable behavior versus implementation details. Code is part of observable behavior when it exposes an operation or state that helps the client achieve one of its goals. Any other code is an implementation detail.
  所有生产代码都可以沿两个维度分类：公共 API vs. 私有 API，以及可观察行为 vs. 实现细节。当代码暴露了能帮助客户端达成目标的操作或状态时，它就是可观察行为的一部分。其他任何代码都是实现细节。
• Well-designed code is code whose observable behavior coincides with the public API and whose implementation details are hidden behind the private API. Code leaks implementation details when its public API extends beyond the observable behavior.
  设计良好的代码，是可观察行为与公共 API 一致、实现细节隐藏在私有 API 后面的代码。当代码的公共 API 超出了可观察行为范围时，就泄漏了实现细节。
• Encapsulation is the act of protecting your code against invariant violations. Exposing implementation details often entails a breach in encapsulation because clients can use implementation details to bypass the code’s invariants.
  封装是保护代码免受不变量破坏的行为。暴露实现细节通常意味着封装被破坏，因为客户端可以利用实现细节绕过代码的不变量。
• Hexagonal architecture is a set of interacting applications represented as hexagons. Each hexagon consists of two layers: domain and application services.
  六边形架构是一组相互交互的应用，每个应用用六边形表示。每个六边形由两层组成：领域层和应用服务层。
• Hexagonal architecture emphasizes separation of concerns between domain and application services, one-way dependencies from application services to domain, and external access through common interfaces maintained by application services.
  六边形架构强调领域层与应用服务层之间的关注点分离、从应用服务层到领域层的单向依赖，以及外部应用通过应用服务层维护的公共接口访问系统。
• Each layer in a hexagon exhibits observable behavior and contains its own set of implementation details.
  六边形中的每一层都会表现出可观察行为，并包含自己的一组实现细节。
• There are two types of communications in an application: intra-system and inter-system. Intra-system communications are communications between classes inside the application. Inter-system communication is when the application talks to external applications.
  应用中有两类通信：系统内通信和系统间通信。系统内通信是应用内部类之间的通信；系统间通信是应用与外部应用之间的通信。
• Intra-system communications are implementation details. Inter-system communications are part of observable behavior, with the exception of external systems that are accessible only through your application. Interactions with such systems are implementation details too, because the resulting side effects are not observed externally.
  系统内通信是实现细节。系统间通信是可观察行为的一部分，但只能通过你的应用访问的外部系统除外。与这类系统的交互也是实现细节，因为其产生的副作用无法从外部观察到。
• Using mocks to assert intra-system communications leads to fragile tests. Mocking is legitimate only when it’s used for inter-system communications—communications that cross the application boundary—and only when the side effects of those communications are visible to the external world.
  使用 mock 对系统内通信做断言会导致脆弱测试。只有当 mock 用于系统间通信，也就是跨越应用边界的通信，并且这些通信的副作用对外部世界可见时，mock 才是合理的。