spring - 如何将 TDD 应用于逐层封装设计？

Question

我已经阅读了很多关于 TDD 的内容，特别是关于各种实践和经验、注意事项和注意事项，在尝试将它应用到具有持久性和 REST 的 Spring Boot 应用程序上之后，我仍然对几个方面感到困惑，所有这些都是由特征。

StackOverflow 上的许多博客文章和答案都建议我们应该测试接口(interface)而不是实现。
然而，像 Steve Freeman 和 Nat Pryce 的“Growing Object-Oriented Software, Guided by Tests”中的例子，提出了完全不同的方法，
因为它们都主要测试实现，断言方法调用的数量等。所以我们的测试实际上变得依赖于实现本身。
当然，我们可以使用控制反转——通过构造函数传递依赖关系并在我们的测试中模拟它们，但是模拟一个 CRUD 存储库真的有意义吗？

也许我会给你一个简单的例子来更好地描述这种情况。
假设我们有一个多页的用户信息表单，并且每个表单页面都必须单独保存。

因此，信息包的计划结构可能如下所示:

com
.. example
.... user
...... information
........ basic
.......... + BasicInformationDto
.......... + BasicInformationService
.......... - BasicInformationServiceImpl
.......... - BasicInformationDao
.......... - BasicInformationRepository
........ additional
.......... + AdditionalInformationDto
.......... + AdditionalInformationService
.......... - AdditionalInformationServiceImpl
.......... - AdditionalInformationDao
.......... - AdditionalInformationRepository
........ + InformationRestController

+ is public and - is default access modifier

我的第一个想法:

编写一个简单的 REST 集成测试来测试由
信息休息 Controller 。

用这些创建 InformationRestController
映射。

为 BasicInformationService 创建测试，创建一个
BasicInformationServiceImpl 对象，模拟 BasicInformationRepository
并测试存储库的保存方法是否只被调用一次。

为 BasicInformationService 创建类，
BasicInformationServiceImpl 和 BasicInformationRepository 与
基本信息道。

重构、实现细节、dto 和 dao
字段等

如果我后来决定使用存储库的#saveAndFlush 怎么办？一个单元测试因为这么小的变化而需要重构是正常的吗？
如果我只测试接口(interface)，我如何测试具有不同依赖项的不同实现？

那么，如何使用 TDD 来设计，例如 BasicInformationService 的保存方法，如果它只将 DTO 对象映射到 DAO，然后使用 BasicInformationRepository 将其持久化？

Answer 1

简而言之，BDD(行为驱动开发)是 TDD 的一种改进，从测试整个堆栈的验收测试开始，然后根据需要使用单元测试测试驱动细节。 You can unit-test every class if you want, but you don't have to, and I don't where it doesn't add value.在您给出的情况下，我怀疑不需要对大多数组件进行单元测试。

在进行 TDD/BDD 时以已知设计为目标是完全正常的，因为您的框架需要它，或者因为该设计已经在您程序的其他垂直部分中建立。只有最极端的 TDDers 才开始没有框架。你不想做的是组成一个你的框架不需要的大设计，并且测试和重构还没有告诉你你需要。