Mock & Roll will Never Die

If you already have built a "mock system" in order to advance development, why would you need something better? I recently had a good conversation with our East architecture lead Ken Ahrens (see more of his work here) after a great CA World event for ITKO was winding down in Las Vegas. We had a lot of questions in our sessions about the development shop that has already "rolled their own" system of stubs and mocks - and what that meant for Service Virtualization practices.

When a company says they already have a mock system, we normally view that as a very positive sign - and tell them as much.  Often we have to convince customers that incomplete and unavailable systems are development problems that need to be solved, before we can even talk about the idea of Service Virtualization capabilities. Whereas the customer with a mock system already understands this is a real problem that needs to be solved.

I usually comment at this point about how we’ve replaced several mock systems at other customers (banks, utilities, telcos, etc...) with LISA's service virtualization. SV really is the productization of the stub and mock space, with enough sophistication to support more complex logic and performance scenarios. Similar to how you wouldn’t write your own database nowadays, it doesn’t make sense to build your own mock system when there is an industry standard solution for this available.

Some questions that usually come up:

• Does your mock system meet 100% of your needs and is it used on every single project?
• How expensive is the mock system to build and maintain?
• How fast do you need new mock services built, and are they ready on time?

If a development shop is mocking a single binary transaction -- that is a simple enough problem to solve with a bit of code. But as soon as multiple systems talk to each other, and multiple business scenarios need to be validated - the manual stub approach quickly starts to trip over its own weight, and the process of mocking and massaging test data and environments can drastically slow down delivery.

On one recent visit to an East coast utility, the customer team decided that LISA began to win (from a cost perspective) after only 10 rather finite services were mocked.  One of our favorite banks established a "center of excellence" for enabling teams with Service Virtualization instead of stubs, and measured a full return in about 6 months - then did something even more interesting by rapidly fixing issues found in production by virtualizing production behavior into the dev environment.  A successful customer like this doesn't just buy software, they take the adoption of the practice seriously - and it's usually the guys who have experienced the pain of rolling their own mocks that see the potential benefits the fastest.

In short – if you already do mock services we think it’s a good thing, so tell us about your story!

 

Comments

[application testing]

There are many things should be taken into consideration, but you've made a good point here. Thanks a lot for that. I will follow your way soon.

[Jason English]

C'mon ITKO blog readers!! I can tell that almost 2000 read this blog monthly, and tweet our posts, so how about some real comments and questions for us?

[Testing Guru]

want a real comment - there is really no point to this product. Basically provided expensive software for simple mock services and then top it off - calling it "service virtualization" ???