Integration projects come with timing challenges. With every component that needs to be integrated there are questions around the availability of the component for the integration project. What you really are looking for is an approach to develop and test your integration components without being delayed by the other components.
Release-timing challenge
Having worked in integration projects for many years, I always ran across problems with dependencies between different project teams. In these kinds of projects you see a number of project teams developing their own part of the solution at different speeds. This leads to some components being available early in the project and others only arriving at the very last minute. Being responsible for the integration between the components and taking care of the end-to-end solution becomes a release-timing challenge.
Test-timing challenge
Another observation during my projects is that the test environments are not always available. At the same time that we are running our project there is also this other big project running, that completely claims one of the main systems that we also need for our development and testing. Since it is never acceptable to deliver our project later, even because of this other project, we need to find a solution for this test-timing challenge.
Version-timing challenge
Even when you have all the components available during the (integration) project, you may still encounter some problems. You did your development work and created your automated test cases, and then the data in one of the downstream components is changed. Now the test cases fail again. When this has occurred a number of times you will be tempted to not update the test cases any more, which will increase the risk of failing regression tests with new releases. This is the nature of the version-timing challenge.
More mature than stubbing and mocking
Three timing challenges where service virtualization is a useful technique to support the development and test process. A virtual service simulates the behavior of a real service. This includes differences in responses based on the input, simulated delays and error scenarios. A service virtualization platform moves “stubbing and mocking” to a more mature level. A virtual service can already be created long before the actual service is implemented. As soon as the interface specification has reached a reasonable stable level, the virtual service can be created for the relevant scenarios. This allows the other teams to continue their work and already test their code. When a project is threatened by the limited availability of some of the services, it can decide to record the interaction with that service and use that as the basis for a virtual service. The recorded scenarios can easily be enhanced and tailored to the project’s needs. Once the virtual service is up, the development and initial testing no longer depends on the real service.
Predictable results
Another advantage of virtual services is that they produce predictable results. If, for instance, you need to have a customer profile to test some functionality in your project, it would be nice if this would produce the same information for a particular customer each time. Often test data is created by copying production data on a regular basis which makes it highly unlikely that the data will be the same tomorrow. Apart from that, this copying of data can be a resource consuming solution as all data has to be copied, cleaned and anonymized.
Lisa
We’ve seen how service virtualization helps with the timing issues in our projects, by allowing us to test our code earlier and more predictable and removing dependencies. The solution that we use for service virtualization is CA LISA®, as this product has the following benefits for us:
- Easy development of virtual services through recording or from sample messages.
- Built-in logic for request/response value mapping
- Easy maintenance of virtual services, e.g. adding new request/response scenarios
- No coding required for virtual services
- Central infrastructure, so virtual services are available for all projects
- Logging of messages for further investigation in case of problems
- Integration with test automation tools
- Support for different integration types (HTTP/SOAP/JMS/JDBC and others)
Ultimately the use of service virtualization allowed us to “shift left” the testing effort, allowing us to find issues earlier in the development process and making them easier to solve, thus allowing for a shorter time-to-market. After all, in current business it is all about time!
