Search code examples
javaspringspring-cloudspring-cloud-contract

Do we need to stub the other micro service in Spring cloud contract


@marcin

I am doing a pilot on implementing the spring cloud contract for Micro services which has around 50+ services talking to each other. I have few questions which I haven't found the answer precisely in your document.

The service which I am building has controller which processes and transforms my input payload to the desired output in json format. This json is used to build desired structure that should match the response in groovy (Our contract). However the controller, is sending json to another services with some URL as shown below.

request_url=http://localhost:8090/services/rest/transact/v2/pay/validate/0000118228/new response_body=null

Basically it is expecting the Response back from the other service by making use of this json and now response_body=null

My question is do I need to create a stub or mock the service? to make use of this response as an input to produce expected output from the response. Basically the microservice is expecting a ServiceResponse.

Another question is do we need to load in-memory data while doing the contract testing or do we need to just test the controller itself?


Solution

  • I don't really follow your description... "The service which I am building has controller which transforms my input payload sent from groovy and giving the desired output in json format" . Sent from which groovy? Groovy application? Can you explain that in more depth?

    But I guess I can try to answer the question anyways...

    My question is do I need to create a stub or mock the service? to make use of this response as input to produce expected output from the response. It is expecting a ServiceResponse.

    If I understand correctly - service you mean a class not an application? If that's the case then, yes, in the controller I would inject a stubbed service.

    Another question is do we need to load in-memory data while doing the contract testing or do we need to just test the controller itself?

    That's connected with the previous answer. Your controller doesn't delegate work to any real implementation of a service, so no access to the DB takes place. If you check out the samples (https://github.com/spring-cloud-samples/spring-cloud-contract-samples/blob/master/producer/src/test/java/com/example/BeerRestBase.java) you'll see that the base class has mocks injected to it and no real integration takes place

    EDIT:

    "The service which I am building has controller which transforms my input payload sent from groovy and giving the desired output in json format" is actually the description of what is done via the Spring Cloud Contract generated test. The next sentence was

    However the controller, is sending json to another services with some URL as shown below.

    In Contract testing, I don't care what your controller further on does. If it's in the controller where you send the request to some other application then you should wrap it in a service class. Then such a service you would mock out in your contract tests. What we care about in the Contract tests is whether we can communicate. Not whether the whole end to end functionality is working correctly.