CODEWITHSUNDEEP
javacloud-foundrymicroservices
StylePotato
StylePotato

Reputation: 167

Microservices - Stubbing/Mocking

I am developing a product using microservices and am running into a bit of an issue. In order to do any work, I need to have all 9 services running on my local development environment. I am using Cloud Foundry to run the applications, but when running locally I am just running the Spring Boot Jars themselves. Is there anyway to setup a more lightweight environment so that I don't need everything running? Ideally, I would only like to have the service I am currently working on to have to be real.

Upvotes: 3

Views: 7343

Answers (6)

Karl Eriksson
Karl Eriksson

Reputation: 205

There are multiple tools out there that let you create mocked versions of your microservices.

When I encountered this exact problem myself I decided to create my own tool which is tailored for microservice testing. The goal is to never have to run all microservices at once, only the one that you are working on.

You can read more about the tool and how to use it to mock microservices here: https://mocki.io/mock-api-microservices. If you only want to run them locally, it is possible using the open source CLI tool

Upvotes: 2

Danylo Zatorsky
Danylo Zatorsky

Reputation: 6104

It boils down to a test technique that you use. Here my recent answer in another topic that you could find useful https://stackoverflow.com/a/44486519/2328781.

In general, I think that Wiremock is a good choice because of the following reasons:

  1. It has out-of-the-box support by Spring Boot
  2. It has out-of-the-box support by Spring Cloud Contract, which gives a possibility to use a very powerful technique called Consumer Driven Contracts.
  3. It has a recording feature. Setup your Wiremock as a proxy and make requests through it. This will generate stubs for you automatically based on your requests and responses.

Upvotes: 2

Ang
Ang

Reputation: 111

I believe this is a matter of your testing strategy. If you have a lot of micro-services in your system, it is not wise to always perform end-to-end testing at development time -- it costs you productivity and the set up is usually complex (like what you observed).

You should really think about what is the thing you wanna test. Within one service, it is usually good to decouple core logic and the integration points with other services. Ideally, you should be able to write simple unit tests for your core logic. If you wanna test integration points with other services, use mock library (a quick google search shows this to be promising http://spring.io/blog/2007/01/15/unit-testing-with-stubs-and-mocks/)

If you don't have already, I would highly recommend to set up a separate staging area with all micro-services running. You should perform all your end-to-end testing there, before deploying to production.

This post from Martin Fowler has a more comprehensive take on micro-service testing stratey:

https://martinfowler.com/articles/microservice-testing

Upvotes: 3

humblebee
humblebee

Reputation: 1404

For java microservices, you should try Stybby4j. This will mock the json responses of other microservices using Stubby server. If you feel that mocking is not enough to map all the features of your microservices, you should setup a local docker environment to deploy the dependent microservices.

Upvotes: 0

ootero
ootero

Reputation: 3475

An approach would be to use / deploy an app which maps paths / urls to json response files. I personally haven't used it but I believe http://wiremock.org/ might help you

Upvotes: 0

Sergey Alaev
Sergey Alaev

Reputation: 3972

It can be solved if your microservices allow passing metadata along with requests.

Good microservice architecture should use central service discovery, also every service should be able to take metadata map along with request payload. Known fields of this map can be somehow interpreted and modified by the service then passed to next service.

Most popular usage of per-request metadata is request tracing (i.e. collecting tree of nodes used to process this request and timings for every node) but it also can be used to tell entire system which nodes to use

Thus plan is

  1. register your local node in dev environment service discovery
  2. send request to entry node of your system along with metadata telling everyone to use your local service instance instead of default one
  3. metadata will propagate and your local node will be called by dev environment, then local node will pass processed results back to dev env

Alternatively:

  • use code generation for inter-service communication to reduce risk of failing because of mistakes in RPC code
  • resort to integration tests, mocking all client apis for microservice under development
  • fully automate deployment of your system to your local machine. You will possibly need to run nodes with reduced memory (which is generally OK as memory is commonly consumed only under load) or buy more RAM.

Upvotes: 0

Related Questions