December 17, 2017
Easy Way To Test Your OSB Code
Reproducible testing of web services requires mock services. Meet MockMotor.
How Do You Test Your OSB Code?
A composite and often even pass-through service in OSB requires a testing to prove it works.
You may need to test multiple scenarios, including but not limiting to:
- Account-specific logic
- Incorrect inputs
- Backend error conditions
- Partial failures and recovery
- Retries
- Performance under load
How do you do it?
Web Services Testing is a Common Problem
Every time we create web services (OSB or standalone, SOAP or REST, no difference), we have to test them.
It is not as easy as with a standalone code. We cannot use JUnit. We cannot setup fixtures for special cases. We have to call the service endpoint.
That’s where the problems begin.
In half of the cases the service endpoint is not even ready yet. When it is ready, provisioning of the test accounts is hard and tedious. The provisioned accounts often become unusable after completing a scenario. Test environment goes down at worst times, and you’re lucky if you’ve got a notice. Error conditions testing is impossible without interrupting the QA work. And the owner of the environment does not agree to any load tests.
Frustrated, we look for a solution and find mocks.
Web Services Mocking is a Common Solution
If we can simulate the backend service close enough for our testing, we can cover all our bases without depending on the actual backend.
We can setup custom responses depending on the request data, and test our business logic.
We can configure error responses, and test our error handling.
We can load our code with high volumes and see how it behaves without alienating the backend owner.
However, creating a mock service is a project of its own.
The more closely should it simulate the real service the more complex its behaviour should be, the more involved and time-consuming the project becomes. If your code needs to use multiple backend services, the mocking efforts explode and can become impractical.
MockMotor, a Configurable Mock Service
Over the last few years I was working on an application that allows to mock SOAP and REST services quickly and yet flexibly. Its prototypes were used in the projects I did for my clients for both functional and load testing. The dry bones of the original idea were beefed up by the requests and use cases I was getting from the use of my prototype in real projects, real testing.
This year it became release-worthy.
I’m making it available for FREE for single-user scenarios. Teams will need to purchase a commercial license.
MockMotor is a simple application, and yet it can already do a lot:
- Supports SOAP and REST services
- Supports scripts for responses and their properties
- Can handle load test TPSs
- Provides configurable response times
- Seeds test accounts from a spreadsheet
- Has multi-user UI and ACL
- Has change history
- Permits response and service cloning and export
- Can forward requests to real backends
- Supports stateful test scenarios
For example, here is how you can quickly mock a SOAP service:
- Import WSDL
- Update the responses you need
- Point your code to the mock URL
And mocking a REST/JSON service is equally easy:
- Import Swagger
- Update the responses you need
- Point your code to the mock URL
Give it a try a let me know what do you think. Remember, it is FREE for a personal use.
About Me
My name is Vladimir Dyuzhev, and I'm the author of GenericParallel, an OSB proxy service for making parallel calls effortlessly and MockMotor, a powerful mock server.
I'm building SOA enterprise systems for clients large and small for almost 20 years. Most of that time I've been working with BEA (later Oracle) Weblogic platform, including OSB and other SOA systems.
Feel free to contact me if you have a SOA project to design and implement. See my profile on LinkedIn.
I live in Toronto, Ontario, Canada. Email me at info@genericparallel.com