If there are multiple microservices, how should I integration test them?

If there are multiple microservices, how should I integration test them?

I am learning microservice architecture, but now there is some confusion.
situation

there are 4 projects written in golang

orderService
userService
tools
web ( forward HTTP request )

orderService , userService, web communicate via grpc
all api requests through web forwarding to orderService or userService
orderService and userService have their own independent database
they are all in docker containers

confusion
when I want to test a request, I have to do the following steps:
cd orderService
govender update +vendor
go build

cd userService
govender update +vendor
go build

cd web
govender update +vendor
go build

docker-compose build
docker-compose up

when I changed some code, I have to do this steps again.
I think this is unscientific and abnormal. I want to know whether all of these steps are necessary to integration test four microservices in docker.

Solutions/Answers:

Solution 1:

If you change Go code you have to recompile; that’s not abnormal. Go code compiles quickly so that’s usually not a big deal.

I’m not sure why you are running govendor repeatedly. If you are working on a dependency it is often easier to unvendor it temporarily.

To speed things up, don’t use Docker during development; at least not for the Go code. Since Go doesn’t have any dependencies beside itself there’s no advantage to doing this. You can still run backing services (e.g. a database) in Docker, but you don’t have to rebuild and restart that all the time.

Solution 2:

You did not explain what kind of test you want to do. The way you are doing it it seems you are running instances with database so I treat it more like an integration test.

I assume you have written unit tests before doing this.

If you wish to test independently I suggest making use of http://onsi.github.io/ginkgo/

This will help you test most of the apis and business scenario and test the flow of your orderService and userService individually.

Solution 3:

First, I don’t think repeating of go vendor is necessary unless dependency has changed. It should not happen often.

Second, Golang does require you to build/compile, so if you make changes you would have to re-build the service. However, most of the times, you should make changes only to one services to make your life easier. It will make the testing and debugging easier during development.

Lastly, there are a few ways to speed things up with development using docker. I would suggest keep using docker as it will make your devops life easier, although you don’t have to. For simplicity, you can move the build step to Docker container. What you have to do is to copy the dir including the dependency into container and build inside the container (or just do go run inside container). This is OK for development. If you would like to have one set of container definition for development and deployment, you can write a script to compile each services, copy the binary into one directory and have docker copy the binary from that directory. A few lines of python script should be enough. This has the added benefits of using docker-compose where you can stand up the whole services with a single click. Then you can also write your integration test launcher using another docker container which will run your test once and exit.

References