Integration Cases for Apache Dubbo SPI Extensions.
This repository contains a number of projects to illustrate various usages of Dubbo-Spi-Extensions from basic to advanced, pls. check README in each individual sub projects. It is also helpful to cross reference to Dubbo User Manual to understand the features demoed in this project.
What's more, dubbo-spi-extensions .
To compile all samples, run the following command in the top directory of this project, or step into the sub directories to compile one single sample:
It is highly not recommend to build the entire project from the root directory, as building the entire samples can take a long time. Each module in Samples is designed independently so you can first go to the demo directory you care about, then execute the build and run the demo.
For example,
$ cd spi-samples-configcenter/spi-samples-configcenter-consul
$ mvn clean package
You may need to read each individual README under the sub directories if you have to understand how to build and run.
This project is also used for integration tests for dubbo-spi-extensions. If you are just learning how to use Dubbo-Spi-Extensions you don't have to care about this part.
How to build and run a spi-samples test
Dubbo-Spi-Extensions integration test base on docker container, and relies on an image used to run the provider application and test cases.
Integration test leverages docker to setup test environment, more accurately, to start dubbo provider instance, and any other supporting systems like registry center if necessary, in docker.
Please install docker
and docker-compose
first, then build the test image dubbo/sample-test
.
cd dubbo-spi-samples
./test/build-test-image.sh
Use a debian mirror through env DEBIAN_MIRROR
if apt download files slowly,
the following example uses aliyun mirror server http://mirrors.aliyun.com/ubuntu/ :
cd dubbo-spi-samples
DEBIAN_MIRROR=http://mirrors.aliyun.com ./test/build-test-image.sh
Then we use the run-tests.sh
script to run the test cases.
-
Run single test case
cd dubbo-spi-samples ./test/run-tests.sh <project.basedir>
For example, run the
dubbo-spi-samples-annotation
test case:./test/run-tests.sh dubbo-spi-samples-annotation
-
Run all test cases
cd dubbo-spi-samples ./test/run-tests.sh
If docker container fails to startup successfully in any case, you can check log files in directory ${project.basedir}/target/logs
to understand what happens.
Pls. note integration tests rely on a Docker environment, make sure the docker environment is available before running them.
How to add more integration test
If you are interested in contributing more integration test for dubbo, pls. read further to understand how to enable integration test for one particular sample from the scratch.
Please follow the steps below:
-
Add a file named
case-configuration.yml
to test project.This file is used to configure the test modules and environment, including dubbo provider / test services, dependent third-party services.
-
Add a file named
case-versions.conf
to test project.This file is used to configure the supported component version rules to support multi-version testing.
Details of case-configuration.yml
:
Take the case dubbo-spi-samples-annotation
as an example:
services:
dubbo-spi-samples-annotation:
type: app
basedir: .
mainClass: org.apache.dubbo.samples.annotation.AnnotationProviderBootstrap
dubbo-spi-samples-annotation-test:
type: test
basedir: .
tests:
- "**/*IT.class"
systemProps:
- zookeeper.address=dubbo-spi-samples-annotation
- zookeeper.port=2181
- dubbo.address=dubbo-spi-samples-annotation
- dubbo.port=20880
waitPortsBeforeRun:
- dubbo-spi-samples-annotation:2181
- dubbo-spi-samples-annotation:20880
depends_on:
- dubbo-spi-samples-annotation
The project contains a dubbo provider AnnotationProviderBootstrap
and an embedded zookeeper server,
as well as a test class AnnotationServicesIT
.
Therefore, we have to define two services, one service runs AnnotationProviderBootstrap
,
and the other service runs test classes.
The service type
of running dubbo provider is app
, and the service type
of running test is test
.
The project directory is the same as the case configuration directory, so basedir
is .
.
Use hostname to access between containers, the default hostname
of the container is the same as serviceName.
So through dubbo-spi-samples-annotation:2181
, the embedded zookeeper server can be accessed from the test container.
There are many test cases similar to this example, only need to modify the mainClass
and hostname.
Extract the changed as variables, and the unchanged content as templates.
When using the template, you only need to modify the variable value, which makes the case configuration easier.
The above example can use a template app-builtin-zookeeper.yml
, use from
to reference it and override the variable value in props
:
from: app-builtin-zookeeper.yml
props:
project_name: dubbo-spi-samples-annotation
main_class: org.apache.dubbo.samples.annotation.AnnotationProviderBootstrap
zookeeper_port: 2181
dubbo_port: 20880
Another template is app-external-zookeeper.yml
, which supports an external zookeeper service.
you can find all the templates in the directory test/dubbo-scenario-builder/src/main/resources/configs
.
Details of case-versions.conf
:
Version rules for spring app:
# Spring app
dubbo.version=2.7*, 3.*
spring.version=4.*, 5.*
Version rules for spring-boot 1.x app:
# SpringBoot app
dubbo.version=2.7*, 3.*
spring-boot.version=1.*
Version rules for spring-boot 2.x app:
# SpringBoot app
dubbo.version=2.7*, 3.*
spring-boot.version=2.*
For more details, please refer to the following case configurations:
- dubbo-spi-samples-annotation : A simple provider service with builtin zookeeper.
- dubbo-spi-samples-api : A simple provider service with external zookeeper.
- dubbo-spi-samples-chain : A multiple services with external zookeeper.
- dubbo-spi-samples-migration : A compatibility test with the provider and consumer have different dubbo verison.
That's it, then feel free to add more integration test for the Dubbo project, have fun.