Java 六边形中的内置端口如何提高可测试性

在端口和适配器（六边形）体系结构中，您有：

DrivingAdapter -> InboundPort <- [ domain ] -> OutboundPort <- DrivenAdapter

DrivingAdapter->InboundPort OutboundPort OrderServicePort[order domain]->OrderRepositoryPortTL；博士

是的，我同意


我认为端口是一个抽象概念，与语言结构无关。我的意思是，端口并不意味着接口，甚至可能不需要接口。在某些语言中甚至没有接口，因此需要使用其他语言构造完成端口

我还将主/驱动（入站）端口和辅助/驱动（出站）端口视为具有不同具体目标的工件，尽管它们具有作为应用程序核心的入口/出口点的相同想法

在我看来，辅助端口是核心所需工具的“原型”，也是核心所需工具的“原型”。在许多情况下，这个“原型”只是一个接口，但始终将其视为一个接口是有限的。辅助适配器将是该端口的具体实现，围绕一个库进行封装。这是一个强大的cozz，它可以轻松地交换所使用的库，无论是为了测试还是为了方便

但是，主端口是应用程序的入口点，它启动一个用例，它告诉应用程序要做什么以及如何做。这是一个具体的东西，不是原型。它是应用程序的核心。因此，如果我们替换它，我们就是在替换应用程序核心本身。主端口不像辅助端口那样是原型，因此，它本身不需要接口之类的东西

更换它的唯一原因是测试主适配器本身，以确保它们指向正确的用例。在这种情况下，我们需要像接口这样的东西。但在这种情况下，我们无论如何都需要启动应用程序，这通常是最昂贵的部分或测试，因此我们不妨将其作为e2e、功能或集成测试来进行，我们还可以测试核心或其一部分

在某些语言、应用程序或上下文中，在某些边缘情况下，可能需要这样做，也许这是最好的方法。我们不应该说一些教条式的话，比如“永远不做…”或“永远做…”，这取决于上下文

但是，总的来说，我同意你的看法：主端口上的接口对测试没有多大好处，我想进一步说，主端口不需要接口。
我完全不同意

驱动端口在六边形体系结构的可测试性中非常重要，它们是一个关键概念

驱动程序端口是“hexagon”（“hexagon”=“business logic”=“application”）的API。它们是用例（横截面）边界，即六边形的左边缘

在隔离测试hexagon时，针对这些端口运行测试（驱动程序适配器），并“模拟”受驱动端口

如果没有六边形行为的API，您将如何测试六边形行为（功能）？测试API（驱动程序端口）。它们是SUT行为的契约

更重要的是，当您将测试作为回归测试运行时，它们允许您检测业务逻辑错误

另一件有用的事情是，它们允许您实现硬编码的六边形

见此：

非常感谢，在我的问题中，我提到了InboundPorts提供了一个“简化视图”，这确实是您提到的用例api，但我的观点是，它们不必是接口来提高可测试性。DrivingAdapter不必依赖于InboundPort接口来提高可测试性，InboundPort可以是以用例为中心的具体类或抽象类，而不牺牲可测试性。使用抽象掉实现的接口，它提供了实现隐藏。我认为依赖接口通常会提高可测试性，因为您不依赖于具体的类，并且您具有可配置的依赖性。例如，您可以硬编码hexagon，并单独测试驱动程序。关于抽象类，它们类似于接口，我将更进一步，使用抽象方法创建一个接口。目标是测试hexagon行为，我知道的最好的方法是将驱动程序端口作为接口谢谢，有两个原因我会使用接口（1）来隐藏子系统，并在测试SUT时模拟它（2）来简化子系统的视图，该子系统面向一个狭窄的用途，如用例。对于内置端口（2）比（1）更适用，因为我不会模拟内置端口。与我共事过的开发人员重复“最好实现到接口”，机械地使用接口，不必要地以类似于某种ServiceImpl的命名结束，我讨厌这种命名，因为它表示不必要地使用接口。欢呼“不必要地使用接口，最终命名为SomeServiceImpl”。。。这与hex-arch完全不同，在hex-arch中命名端口非常重要，因为端口名应该表示端口用途。Alistair Cockburn建议将端口命名为“用于做某事”（请参阅）。接口也允许封装。关于（1）硬编码，六边形在开发的早期阶段也很有用，用于开发测试适配器
WebController -> OrderServicePort [ order domain ] -> OrderRepositoryPort <- MongoDbOrderRepositoryAdapter