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

Question

我读了很多关于TDD的文章，特别是关于各种实践和经验、应该做的和不应该做的，在尝试将它应用到Spring Boot应用程序上之后，我仍然对几个方面感到困惑，这些应用程序都是通过Feature打包的。

这里关于StackOverflow的许多博文和答案都建议我们应该测试接口而不是实现。然而，例如Steve Freeman和Nat Pryce的《面向对象的软件成长，由测试引导》中的例子，提出了一种完全不同的方法，因为它们都主要测试实现，断言方法调用的数量等等。所以我们的测试实际上变得依赖于实现本身。当然，我们可以使用控制反转--通过构造函数传递依赖项，并在测试中模拟它们，但模拟（比方说）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

null

如果我后来决定使用存储库的#saveandflush怎么办？一个单元测试因为这么小的改动而需要重构，这正常吗？而且如果我只测试接口，我如何测试不同的实现和不同的依赖项来实现它呢？

那么，如果BasicInformationService只将DTO对象映射到DAO并使用BasicInformationRepository持久化，那么如何使用TDD设计BasicInformationService的save方法呢？

Answer 1

简而言之，BDD（行为驱动开发）是对TDD的改进，它从测试整个堆栈的验收测试开始，然后根据需要用单元测试来测试驱动细节。你可以对每个类进行单元测试，如果你想的话，但你不必这样做，我也不想这样做。在您给出的情况下，我怀疑没有必要对大多数组件进行单元测试。

在执行TDD/BDD时，目标是一个已知的设计是非常正常的，这要么是因为您的框架需要它，要么是因为该设计已经在您的程序的其他垂直切片中建立起来了。只有最极端的tder在没有框架的情况下启动。您不想做的是构建一个框架不需要的、测试和重构还没有告诉您需要的大设计。