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
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
- Jenkins2
- SoapUI
- Tomcat
- Docker
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, …
Jenkins2
SoapUI
- 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.
Tomcat
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.
Docker
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.