TL; DR:如何为两个交换信息的服务生成存根(因此它们都是生产者和消费者)?
您好,
我正在开发一个使用微服务架构的应用程序,包括maven,Spring Boot,Spring Cloud Stream,Spring Cloud Contract Verifier和Stub Runner,用于集成测试。我使用事件采购通过Kafka发布事件。所以我有这样的事情:
my-app
|-- pom.xml (sets up both subprojects as children)
|-- person-service (handles person's money)
| |-- src/main/java/person/EventProducer.java (produces a personCreated event)
| `-- src/main/java/person/EventConsumer.java (consumes an objectBought event)
`-- object-service (handles objects that can be bought)
|-- src/main/java/object/EventProducer.java (produces an objectBought event)
`-- src/main/java/object/EventConsumer.java (consumes a personCreated event)
现在,我的问题是,通过Event Sourcing,这两种服务都是生产者和消费者。所以我有两个服务生成存根供其他服务使用,如下所示:
人员服务集成测试
@SpringBootTest(classes = PersonApplication.class, webEnvironment = RANDOM_PORT)
@AutoConfigureStubRunner(ids = "example.com:object-service", stubsMode = LOCAL)
class PersonIntegrationTests extends Specification {
@Inject StubTrigger stubTrigger
// tests
}
对象服务集成测试
@SpringBootTest(classes = ObjectApplication.class, webEnvironment = RANDOM_PORT)
@AutoConfigureStubRunner(ids = "com.example:person-service", stubsMode = LOCAL)
class ObjectIntegrationTests extends Specification {
@Inject StubTrigger stubTrigger
// tests
}
现在,当然,在父项目中运行mvn clean install
会给出错误,因为无论构建顺序如何,其他项目中的存根都尚未生成。
我查看了Spring Cloud Contract Verifier文档及其示例,但我还没有找到适合此方案的解决方案。
现在作为一种解决方法,我先运行mvn clean install -DskipTests
先生成存根,然后mvn clean install
运行所有测试。我还尝试设置两个服务都可以使用的外部合同项目,但每个服务仍然会生成自己的存根。我认为将stubsMode更改为CLASSPATH也不会有任何帮助,因为仍然需要在第一时间创建存根...
我创建了一个"存根服务"这将实现每个服务的生成器,以便每个项目都将它引用到存根(因此我在每个集成测试中都使用ids = "com.example:stub-service"
)。但这似乎很麻烦,并且可能导致人为错误,因为合同中的每个更改以及事件存储中发布的每个附加服务都需要反映在存根服务中。
我的问题是:在运行集成测试之前,是否有更好的方法为两个项目生成存根?我希望能够仅使用mvn clean install
构建和运行集成测试。
答案 0 :(得分:1)
这是一个非常好的问题。这是鸡蛋和鸡蛋一样的问题。
现在作为一种解决方法我首先运行mvn clean install -DskipTests以首先生成存根,然后使用mvn clean install来运行所有测试。我也尝试过设置两个服务都可以使用的外部合同项目,但是每个服务仍然会生成自己的存根
这似乎很合理。您还可以将一些测试放在不同的套件中,然后首先使用一个配置文件(例如producer
)运行测试,然后再运行另一个配置文件(例如consumer
)。但你所做的似乎是最快的。
您可以在Spring Cloud Contract中提出问题,我们可以尝试调查如何在这种情况下让开发人员的生活更轻松。