Everybody knows (or should know) that automated testing is a must when you develop applications. If you don’t test your software, you run a big risk of releasing software that doesn’t function well. Although testing doesn’t guarantee your software is bug free, it will decrease the number of bugs in your released software. Most developers find testing boring and time consuming, that’s exactly why a lot of testing is, or should be, done automatically: Automated testing tools don’t get distracted, bored or whatever but do the task without complaints and reports back on the results.
It goes without saying that automated testing results in better software and as a logical result happier users. The same applies to automated testing of integration services. But how do you automatically test services that depend on back end services? The short answer is: by using stubs.
Stubs are pieces of software that simulate the behavior of real systems. They give us the means to test software without depending on other applications or services.
This blog describes how you can do test your ESB/EI services using the following tools:
- WSO2 ESB/WSO2 EI
In blog part 2, I’ll test a service (REST API) which transforms a REST request into a SOAP request, invokes a back-end service stub and finally transforms the SOAP response into a REST response. After all this blog is not about writing nice meaningful services, it is about testing services.
The tools used
Let’s first look at the tools that we are going to use.
WSO2 ESB / WSO2 EI
Of course, I need an instance of the Enterprise Service Bus (ESB) or its successor the Enterprise Integrator (EI) to deploy the services on.
What else do we need?
I assume everybody reading blogs like this one, knows about Jenkins. IF not Jenkins is an open source build server, which can be used to build (and test) code automatically when changes are committed to the Source Configuration Management (SCM) systems like Git, SVN, …
I won’t describe Jenkins into details here, but I want you to know that in Jenkins2 the ‘Pipeline as Code’ is introduced: The steps executed while building, testing and deploying a piece of software are called a pipeline in Jenkins. In Jenkins2 you no longer need to define these steps in the admin UI of Jenkins, you can now describe these steps in a configuration file which must be named Jenkinsfile. This file can be checked in into your version control system in your project, along with your code.
Another of my favorites is SoapUI, a nice tool which can be used in multiple ways. For instance, it can be used to:
- call services manually during development (both rest and soap)
- run test scripts
- create back-end server mocks
- run these back-end mocks
- export them as war file(s), which can be deployed on a servlet container like Tomcat, WSO2AS, Jetty, …
Although stubs and mocks are not exactly the same, they are very much alike. In this blog both terms are used. Because SoapUI offers the facility to ‘create a Mock Service’ the term mock is used in the test scripts, where in this case ‘stub’ would be better.
In this blog, I’ll use Tomcat 8 as servlet container to deploy the stub war files on. Instead of Tomcat, another servlet container like WSO2AS or Jetty could be used as well.
Why would you want to deploy the stubs on Tomcat while SoapUI itself can be used to run the stubs during the tests? The answer to this question is quite simple: If your tests involve multiple stubs, you can use SoapUI to run multiple stub services, but every stub service will need its own port. When you deploy the stub services on a servlet container like Tomcat, all stub services are available on the same port. Which makes life easier, especially when you want this single port to be determined dynamically.
I’ll run Tomcat in a Docker container, this way every build will get its own clean tomcat instance and builds won’t interfere with each other. I won’t describe Docker in detail in this blog either, in the unlikely case you haven’t heard of Docker: Docker is a lightweight virtualization technology which amongst others allows you to run multiple applications on a single machine where these machines won’t interfere with each other.
By dynamically determining the host port that is mapped onto port 8080 of the container, multiple tests can run simultaneously on the same Jenkins machine.
As mentioned before, SoapUI can be used to run the stub services too, but by using tomcat I can deploy multiple stub services at the same time. Simply said, I can stub multiple back end services together.
In the next blog I will deep dive into the Jenkinsfile and I’ll explain the service I’m testing.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.