Create the Service That Meets Your Team's Needs

Blog Post created by Mike_Gavaghan Employee on Oct 19, 2017

Teamwork is important when developing applications, but when creating virtual services it’s important that each team work independently and create the services that meet their own unique needs. Virtualizing a service just once so a single instance can be used across multiple teams is a common mistake that often leads to big problems.


“Reuse” is a valuable concept in the software development lifecycle and virtual services provide many cost saving opportunities for reuse – particularly for regression testing in subsequent development cycles. However, the “One Size Fits All” antipattern captures a misguided and ill-advised effort at virtual service reuse.


Virtualize Only What You Need

Each team will require virtualization of only a small percentage of the dependent system. Implementing the behavior required by all teams will cause the virtual service to grow large and complex – possibly as complex as the real system – and this will have a negative impact on your ability to deliver on the promise of reduced testing costs and timelines.


Independent Requirements: Independent team needs in virtual services is analogous to “decoupling” in object oriented programming. Two orthogonal system behaviors should not be combined into the same class. Code maintainability is improved by decoupling the two behaviors and encapsulating them in separate classes. Failing to do so comes with higher costs for both testing and long term maintenance. Similarly, trying to blend the independent needs of separate teams into a single virtual service impedes the efforts of the testers trying to manage it.


Overlapping Requirements: Even when two teams have overlapping needs for the virtualization of certain operations, their needs are rarely identical. Although they may be invoking the same operations, their transaction matching strategies will be different. Also, while one team may require an operation to participate in a conversation, another team might be satisfied with stateless transactions. There’s no need to make both teams deal with the complexity of stateful transactions when not necessary.


Different Needs, Different Uses

Virtual services deliver great value by providing complete control over test data. However, because each team has its own test data management needs and requirements, there will be little opportunity to reuse request/response pairs. In fact, differing test data needs make the requirements of each team independent rather than overlapping – even if the same operations are being invoked.


Virtual services built for functional testing are generally very different than those built for performance testing. Virtual services for performance testing generally have limited data and are optimized to maximize throughput. Alternatively, functional testing requires rich test data and complex conversation logic, which comes at the cost of performance. Trying to use these same services for both testing needs means either:


  • There will be too little data for functional testing, or
  • Insufficient support for a high load, unless VSE is on a very high end machine.


Finally, a combined service image does not allow each team to independently version the virtual service.


A Better Approach

The best virtual services are simple, cheap, and easy to maintain. To achieve that ideal, allow each team to evolve and version their virtual services independently and according to their unique needs. After all, sharing a common virtual service is not really “reuse” when each team has its own requirements. There is no cost saving when there is no shared behavior.


If a virtual service is simple, it can be built quickly. Over the testing lifecycle, far more time will be spent on the actual analysis of virtual service requirements than on the implementation.