Beliebte Suchanfragen
|
//

Mule ESB Testing (Part 3/3): System End-to-End Testing with Docker

14.6.2015 | 8 minutes of reading time

As generally acknowledged testing is an important part of the software development process. Tests should be applied during each phase of the software development process from developer tests to acceptance tests. In software engineering comprehensive and automated test suits will secure the quality of software and can provide a safety net for regression and incompatible changes.

In Mule ESB integration projects these same issues arise. Components used in Mule flows, the flows themselves and the integration of flows in a system context need to be tested thoroughly.

This article is the last one in a series of articles about testing Mule ESB projects on all levels (part 1 , part 2 ). It is focusing on the overall system end-to-end test in a Mule project which is performed by setting up the infrastructure with the ESB and a mock server using Docker.

Infrastructure

To perform a system end-to-end test for a Mule application we need at least three different system components:

  • App: First of all we need the Mule application under test.
  • Tester: The testing part performs testing of the application under test. Such testing can be performed by simple tests which perform API calls and verify the results or complex orchestrated calls with a testing tool such as JMeter .
  • Mock: Then we need one or multiple system mocks, which represent the systems the application is dependent on. Mountebank can provide such functionality.

Such a system end-to-end setup would look like this:

Docker

Docker is an Open Source technology which allows the virtualization of machines as isolated containers on the host system. It provides the fast and resource efficient creation of containers on a host by using Linux technologies such as cgroups and namespaces. This enables the creation of portable, reproducible and immutable infrastructures. These are a huge bonus for the creation, reproducible execution of test scenarios which include infrastructure.

For a better integration of such a system end-to-end test into a continuous integration pipeline the usage of containerization technology is an advantage. Usage of Docker for example, will allow the fast start up and stopping of an isolated Mule instance with the application and a mock server.

Application under test

Let’s assume for example the following simple scenario. A Mule application provides a REST API on port 8080 which internally calls another backend REST service on port 9000. Such an application could look like that:

We see in this example an HTTP endpoint which listens on port 8080 and routes all requests to an REST API router. The request to the /myResource will go into the bottom sub flow and will trigger an outbound HTTP call to a server on port 9000. The result is transformed into a string and returned to the caller afterwards. In case of exceptions, an exception strategy will return the approriate result.

We assume we have set up our Mule application already as a single application in a Docker container, as described in this blog post.

Mock server

To allow the Mule application to perform calls to potential backend services in a system end-to-end scenario, a technology such as Mountebank can be used.

Mountebank is an open source tool, which provides cross-platform, multi-protocol test doubles on a network. An application which is supposed to be tested, just needs to point to the IP or URL of a Mountebank instance instead of the real dependency. It allows to test your application through the whole application stack, as you would with traditional stubs and mocks. Supported protocols include HTTP, HTTPS, TCP and SMTP.

For our scenario, the Mountebank imposter would be defined as followed, returning a mocked response on port 9000:

1{
2  "port": 9000,
3  "protocol": "http",
4  "name": "My Mock",
5  "mode": "text",
6  "stubs": [
7    {
8      "responses": [
9        {
10          "is":
11          {
12            "statusCode": 200,
13            "headers": {
14              "Content-Type": "application/json"
15            },
16            "body": "{ \"message\": \"You got mocked data\" }"
17          }
18        }
19      ],
20      "predicates": [
21        {
22          "equals": {
23            "path": "/anotherResource"
24          }
25        }
26      ]
27    }
28  ]
29}

We assume we have set up our mock server in a Docker container as well, as described in this blog post.

Test Definition

Now to define our test, we use a simple JUnit integration test using the rest-assured library integrated into a Maven build. It’s calling the REST API and verifying that the result is the mocked data from the mock server. At that point calls to the mock server via the Mountebank REST API can be performed for verification purposes as well.

Such a test would look like this:

1public class SystemIT {
2 
3  @Test
4  public void testMyResource() {
5 
6    RestAssured.baseURI = System.getProperty("system.url");
7    RestAssured.defaultParser = Parser.JSON;
8 
9    // Verify an system end-to-end call
10    given()
11            .param("mimeType", "application/json")
12            .get("/api/myResource")
13            .then().assertThat()
14            .header("content-type", containsString("application/json"))
15            .body("message", equalTo("You got mocked data"));
16  }
17}

Test Configuration

The automation of this scenario is performed by using Maven and the docker-maven-plugin . For that purpose we defined two Docker images, one for the Mule app and one for the mocks server:

1<plugin>
2  <groupId>org.jolokia</groupId>
3  <artifactId>docker-maven-plugin</artifactId>
4  <version>0.11.5</version>
5 
6  <configuration>
7    <dockerHost>${boot2docker.url}</dockerHost>
8 
9    <images>
10      <!-- Mule app container configuration -->
11      <image>
12        <name>mule-app</name>
13        <alias>mule-app</alias>
14        <run>
15          <ports>
16            <port>${webservice.port}:${webservice.port}</port>
17          </ports>
18          <links>
19            <link>rest-mock:backend</link>
20          </links>
21          <wait>
22            <!-- The plugin waits until this URL is reachable via HTTP ... -->
23            <log>Server startup</log>
24            <url>${boot2docker.address}:${webservice.port}/api/console</url>
25            <time>8000</time>
26            <shutdown>500</shutdown>
27          </wait>
28          <log>
29            <prefix>Mule</prefix>
30            <date>ISO8601</date>
31            <color>blue</color>
32          </log>
33        </run>
34        <build>
35          <from>cpoepke/muledocker:latest</from>
36          <tags>
37            <tag>mule-app</tag>
38          </tags>
39          <command>/opt/mule-standalone-3.6.1/bin/mule -M-Dbackend.host=$BACKEND_PORT_9000_TCP_ADDR -M-Dbackend.port=$BACKEND_PORT_9000_TCP_PORT</command>
40          <assembly>
41            <mode>dir</mode>
42            <basedir>/</basedir>
43            <descriptor>assembly-app.xml</descriptor>
44          </assembly>
45        </build>
46      </image>
47      <!-- Backend mock container configuration -->
48      <image>
49        <name>rest-mock</name>
50        <alias>rest-mock</alias>
51        <run>
52          <ports>
53            <port>2525:2525</port>
54            <port>9000:9000</port>
55          </ports>
56          <log>
57            <prefix>Mock</prefix>
58            <date>ISO8601</date>
59            <color>yellow</color>
60          </log>
61          <wait>
62            <!-- The plugin waits until this URL is reachable via HTTP ... -->
63            <log>Server startup</log>
64            <url>${boot2docker.address}:2525</url>
65            <time>2000</time>
66            <shutdown>500</shutdown>
67          </wait>
68        </run>
69        <build>
70          <from>cpoepke/mountebank-basis:latest</from>
71          <tags>
72            <tag>rest-mock</tag>
73          </tags>
74          <command>mb --configfile /mb/imposters.ejs --allowInjection</command>
75          <assembly>
76            <mode>dir</mode>
77            <basedir>/</basedir>
78            <descriptor>assembly-mock.xml</descriptor>
79          </assembly>
80        </build>
81      </image>
82    </images>
83  </configuration>

You will notice in this example the port mapping and Docker links between the two containers.

To start and stop the containers for a test, the following integration-test configuration needs to be set up to configure the Maven phases:

1<!-- Connect start/stop to pre- and
2       post-integration-test phase, respectively if you want to start
3       your docker containers during integration tests -->
4  <executions>
5    <execution>
6      <id>start</id>
7      <phase>pre-integration-test</phase>
8      <goals>
9        <!-- "build" should be used to create the images with the
10             artefacts -->
11        <goal>build</goal>
12        <goal>start</goal>
13      </goals>
14    </execution>
15    <execution>
16      <id>stop</id>
17      <phase>post-integration-test</phase>
18      <goals>
19        <goal>stop</goal>
20      </goals>
21    </execution>
22  </executions>
23</plugin>

This will start the Docker containers with docker:start before in the Maven pre-integration-test phase and stop them with docker:stop in the Maven post-integration-test phase.

To execute the integration test we use the failsafe plugin which starts our system end-to-end test in the Maven integration-test phase with our environment variables.

1<!-- fails-safe-plugin should be used instead of surefire so that the container gets stopped even
2     when the tests fail -->
3<plugin>
4  <groupId>org.apache.maven.plugins</groupId>
5  <artifactId>maven-failsafe-plugin</artifactId>
6  <version>2.18.1</version>
7  <executions>
8    <execution>
9      <id>integration-test</id>
10      <phase>integration-test</phase>
11      <goals>
12        <goal>integration-test</goal>
13      </goals>
14    </execution>
15    <execution>
16      <id>verify</id>
17      <phase>verify</phase>
18      <goals>
19        <goal>verify</goal>
20      </goals>
21    </execution>
22  </executions>
23  <configuration>
24    <systemPropertyVariables>
25      <!-- Needs to be repeated here (the following two lines strangely doesn't work when the next line is omitted although)
26           Maven, you little sneaky beast ... -->
27      <!--<system.port>${webservice.port}</system.port>-->
28 
29      <!-- Map maven variables to system properties which in turn can be used in the test classes -->
30      <system.url>http://${boot2docker.ip}:${webservice.port}</system.url>
31    </systemPropertyVariables>
32  </configuration>
33</plugin>
34 
35<!-- Tell surefire to skip test, we are using the failsafe plugin -->
36<plugin>
37  <groupId>org.apache.maven.plugins</groupId>
38  <artifactId>maven-surefire-plugin</artifactId>
39  <version>2.18.1</version>
40  <configuration>
41    <skip>true</skip>
42  </configuration>
43</plugin>

Notice: Do not to forget the port forwarding on Mac and Windows for boot2docker!

Test Execution

The execution of the test and hence the integration into a continuous integration or delivery process can be started by issuing the “mvn verify” command. You see in this log, how all containers are started, the execution waits until they are up, performs the system end-to-end test and how the containers are stopped again:

1cpoepke:sys-test cpoepke$ mvn verify
2[INFO] Scanning for projects...
3[INFO]                                                                         
4[INFO] ------------------------------------------------------------------------
5[INFO] Building System Test - Mule End to End Test Demo 1.0.0-SNAPSHOT
6[INFO] ------------------------------------------------------------------------
7...
8[INFO] --- docker-maven-plugin:0.11.5:build (start) @ sys-test ---
9[INFO] Reading assembly descriptor: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/src/main/docker/assembly-app.xml
10[INFO] Copying files to /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/mule-app/build/maven
11[INFO] Building tar: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/mule-app/tmp/docker-build.tar
12[INFO] DOCKER> Created image [mule-app] "mule-app"
13[INFO] DOCKER> Tagging image [mule-app] "mule-app": mule-app
14[INFO] Reading assembly descriptor: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/src/main/docker/assembly-mock.xml
15[INFO] Copying files to /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/rest-mock/build/maven
16[INFO] Building tar: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/docker/rest-mock/tmp/docker-build.tar
17[INFO] DOCKER> Created image [rest-mock] "rest-mock"
18[INFO] DOCKER> Tagging image [rest-mock] "rest-mock": rest-mock
19[INFO] 
20[INFO] --- docker-maven-plugin:0.11.5:start (start) @ sys-test ---
21[INFO] DOCKER> Starting container 4ee608ab49b9
22[INFO] DOCKER> Creating and starting container 4ee608ab49b9 [rest-mock] "rest-mock"
232015-06-09T22:49:36.349+02:00 Mock> mountebank v1.2.122 now taking orders - point your browser to http://localhost:2525 for help
24[INFO] DOCKER> Waited on url https://192.168.59.103:2525 and on log out 'Server startup' 2091 ms
25[INFO] DOCKER> Starting container b7069c9653cd
26[INFO] DOCKER> Creating and starting container b7069c9653cd [mule-app] "mule-app"
272015-06-09T22:49:38.634+02:00 Mule> MULE_HOME is set to /opt/mule-standalone-3.6.1
282015-06-09T22:49:38.642+02:00 Mule> Running in console (foreground) mode by default, use Ctrl-C to exit...
292015-06-09T22:49:38.649+02:00 Mule> MULE_HOME is set to /opt/mule-standalone-3.6.1
302015-06-09T22:49:39.845+02:00 Mule> Running Mule...
31...
32[INFO] DOCKER> Waited on url https://192.168.59.103:8080/api/console and on log out 'Server startup' 8114 ms
33[INFO] 
34[INFO] --- maven-failsafe-plugin:2.18.1:integration-test (integration-test) @ sys-test ---
35[INFO] Failsafe report directory: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/failsafe-reports
36 
37-------------------------------------------------------
38 T E S T S
39-------------------------------------------------------
40Running de.cpoepke.mule.demo.SystemIT
41Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.871 sec - in de.cpoepke.mule.demo.SystemIT
42 
43Results :
44 
45Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
46 
47[INFO] 
48[INFO] --- docker-maven-plugin:0.11.5:stop (stop) @ sys-test ---
49[INFO] DOCKER> Stopped and removed container b7069c9653cd [mule-app] "mule-app"
50[INFO] DOCKER> Stopped and removed container 4ee608ab49b9 [rest-mock] "rest-mock"
51[INFO] 
52[INFO] --- maven-failsafe-plugin:2.18.1:verify (verify) @ sys-test ---
53[INFO] Failsafe report directory: /Volumes/Projects/Current/Mule-ESB/mule-end-to-end-test-demo/sys-test/target/failsafe-reports
54[INFO] ------------------------------------------------------------------------
55[INFO] BUILD SUCCESS
56[INFO] ------------------------------------------------------------------------
57[INFO] Total time: 21.396 s
58[INFO] Finished at: 2015-06-09T22:49:50+02:00
59[INFO] Final Memory: 22M/206M
60[INFO] ------------------------------------------------------------------------

Conclusion

Thorough testing is considered commonly an essential part of good software development practices. Performing this automated and on all levels of the testing pyramid is desired. Hence the issue of testing a mule application end-to-end will come up at some point.

We have shown in this article how a fully automated system end-to-end test infrastructure can be set up. We used for the purpose of testing a Mule application Docker and Mountebank. Nevertheless this test setup can also be reused for other scenarios and application types where an end-to-end test is required.

A full running example of this scenario is available on Github as a demo.

Series

This article is part of the Mule ESB Testing series:

|

share post

Likes

0

//

More articles in this subject area

Discover exciting further topics and let the codecentric world inspire you.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.