你所解释的更像是一个端到端的测试，有一些端到端的测试是可以的，但是它们通常是非常昂贵的编写、维护和脆弱的。
对我来说，服务中的测试应该给予你信心，你交付的软件将在生产中工作，所以也许有一个非常小数量的端到端测试，检查一切都是正确地粘合在一起，但是大多数实际的功能应该在正常的测试中进行。检查下游服务关闭时发生的情况的结束测试。
另一个非常重要的方面是测试是为其他开发人员编写的，而不是为编译器编写的，所以保持测试简单对于可维护性来说是很重要的。我想强调这一点，因为如果一个测试有10行Assert，对于大多数开发人员来说是不可读的。即使是10行代码的测试也很难理解。
下面是我尝试构建服务的方法：
如果您熟悉ATDD和六边形体系结构，那么大多数特性都应该在测试适配器时进行测试，这样可以让测试运行得非常快，并且可以使用testdouble来处理适配器。这些测试不应该与JVM之外的任何东西进行交互，这样可以让您对特性的工作有一个很好的信心。如果特性有太多的副作用，我尝试仔细地挑选Assert。例如，如果一个特性要创建一个帐户，我不会检查该帐户是否真的在DB上（因为该断裂的机会极小），但我会检查所有需要触发的消息是否都已发送。有时，如果测试开始变得不清楚，我确实会创建多个测试。例如，一个测试检查返回值，另一个测试验证副作用（例如，生成的消息）。
通过单元测试和集成测试（这里我指的是与外部服务交互的测试类）对关键代码进行最低限度的良好覆盖，可以建立类按预期工作的信心。因此，端到端测试不需要覆盖组合的最小范围。
最后进行少量的端到端测试，以确保所有组件都很好地粘合在一起。
底线：使用相同的设置创建多个测试，如果这有助于理解代码。

编辑

关于 * 集成测试 *：我把集成测试称为与外部服务（数据库、队列、文件等）交互的一个类或一小组类;组件测试用于验证单个服务或模块;和端到端测试，这些测试可以测试所有服务或模块的协同工作。
你提到的存储过程改变了方法。你有单元测试吗？否则你可以写一些 * 集成测试 * 来验证存储过程是否按预期工作。
关于测试的可读性：对我来说，真实的的测试是询问另一个团队或产品所有者，询问他们测试名称、设置、Assert内容以及这些内容之间的关系是否清楚。2如果他们有困难，这意味着测试应该简化。