Let's look into the world of mocking; you've probably come across it many times before, especially if you're a developer, but let's look specifically into what unique about Service Mocking. But first, let's try a definition.
What is Mocking?
What is Mocking? Let’s try a definition:
“Service Mocking, or simulation, is the practice of creating a facsimile environment that works similar to the environment you’re facsimileing”.
That’s fancy speak for saying “You build something that works as something else”
Mocking is also called Isolation, Simulation, or Virtualization, but those are term basically created to move the lowly practice of mocking higher into the value chain. So, for all purposes Isolation, Simulation, and Virtualization are the same as mocking, just much more expensive. Let's call it mocking and move on to the uses of it.
When do I Use Mocking?
Simple; you should use mocks when you can’t use the real thing. Of course it’s not that easy when you look into it more carefully, so let’s look at some of the how’s and what’s.
What are the Advantages of Mocking?
In better order to understand when to use it, let’s look at the advantages of Mocking.
You can create tests in advance; TDD FTW!!!
This one is one of the stronger benefits. If you create a Mock you can write Service Tests before the service is created, giving you the ability to add the tests to your automation environment in the development process. In other words, Service Mocking gives you the ability to use Test Driven Development.
Teams can work in parallel
This is similar to the above; create tests for code that does not exist. But the previous point was for the developer who writes tests, this one is for the Testing Team. How does the team start creating tests when you don’t have anything to test? Mock it and write tests against the Mock! This means it’s actually possible for the QA Team to have a full suite of tests ready when a service is ready to be tested; we don’t have downtimes when one team waits for the other to finish. This makes the financial argument for mocking particularly strong.
You can create proof of concepts or demos
Since Mocks can (done levelheadedly) be very cost efficient to make, Mocks can be used to create a proof of concept, as a wireframe, or as a demo for something you’re considering building. This is very powerful and gives a good ground for making decisions about both whether to go ahead with a development project or not, but most importantly for actual design decisions.
You can write test for resource not accessible
This is one of those benefits that doesn’t fall into the actual benefits category, but rather works as a life saver. Ever wanted to test or use a service, only to get told that the service is behind a firewall and that that firewall can’t be opened for you or that you’re an authorized to use it? When you do, a MockService placed in an accessible place, including on your local computer, is a life saver.
Mock can be delivered to the customer
There are cases where there are reasons why you can’t allow access to your test systems for external sources, like partners or customers. These reasons can be access security, sensitivity of information, or just the fact that the test environment might not be accessible 24/7. In these cases; how do you provide a test system for your partner or customer to start development or test against? An easy solution is to provide a mock, either from your network or from your customers own network. A soapUI mock is extremely easy to deploy, it can either run in soapUI or exported as a .WAR file and placed in your java server of choice.
Save yourself from the money pit
Some systems used in your environment might not be yours and might even be associated with a cost per transaction. This can be very painful during testing and especially during Performance Testing. An easy way to rid yourself of this pain is to Mock the subsystem. You can get both perfectly fine integration and tests with a Mock, and the costs you can save can be very substantial. The money saving aspect can really come into play when you do load tests or build load tests.
You can isolate systems
Sometimes you would like to test a part of your system without having other system parts affect it. This because the other systems will add noise to the test data and make it harder to make good conclusions from the data collected. Using mocks you can remove all dependencies mocking all systems except the one system you need to pinpoint in your tests. When doing mocks for isolation these mocks can be made extremely simple but reliable, fast, and predictable. This gives you a test environment where you have removed all stochastic behavior, have repeatable patterns and can monitor specific systems well.
You can test the Live Environments before you have the service in it
Sometimes it’s beneficial to do some sanity tests of the actual physical environment before you actually have a service to put in it. Placing the Mock in the Live Environment can reveal problems with network resources, quirks in the server setup or errors in the configuration of external systems like monitoring systems. Now, let’s make clear that placing the Mock in the Live Environment is not a magic bullet; in fact it’s not even a bullet, but it can help you weed out the worst errors or behaviors. But please, do not think you’re safe just because the Mock test in live environment.
What are the disadvantages of Mocking?
Everything is not of course fine and dandy with Service Mocks; here are few disadvantages with them.
You have to do Double work (and sometimes quite a lot)
Let’s face it; the Mock you create is discarded after use in many cases. The value of the Mock is only based on how well you can use it during its short life span. For that reason it’s a good idea to balance the effort you put into the Mock ; you can get very far by creating a pretty rudimentary mock and then expand it as far as need be.
Unless you work with your mock locally it will still need to be deployed somewhere. Just as there is no live Service, there might also be no live environment available or the red tape in deploying on an existing server might be quite hard to cut through. Having somewhere to place your Mock can be an issue.
Even Mocks gets bugs
Who says the Mock work as it should? Mocking is in itself development work and subject to bugs. One solution to buggy mocks would be to do extensive testing of the Mock s, but it’s very easy to overcomplicate the issue and forgetting about what’s the focus. It’s also very easy to get into a situation where the tests aren’t trusted since they were built working with a potentially faulty Mock. The solution to this is actually testing that will satisfice and a Mock that’s good enough; simple but robust.
Differences between live and mocked environ
The difference between a Mock and what it’s mocking is that of the difference between you and a photo of you. The Mock is just a representation of what it’s mocking. And just like a photo can misrepresent you, so can the Mock misrepresent your service. There’s always a chance that your mock implementation is not accurate. Most often it will be an ideal of the service you’re mocking; it will not have any of the idiosyncrasies of the service itself and few of the bugs.
It’s not live is it?
Just like the implementation of a Mock is an idealized image of a Service, so is the deployment an idealized version of the live environment. In general we have created the Mock in order to have a stable test environment and in order to achieve this we have removed a lot of the complexities of the live environment. This is worth mentioning, since all too often the Mock will get the blame for bugs found when tests move over to the actual service; “Why didn’t you find it before?”. Make sure that all stakeholders understand that the actual environment will introduce complexities.
Enter the Uncanny Valley
One problem we’ve been introduced to with soapUI is that mocks are way too good and way too “lifelike” and it’s often tempting for management to extend the functionality of the Mock and to move the Mock into the live environment. Don’t do it! Mocking is for Mocking and nothing else. Basta!
You will also have to make sure that even though the Mock acts like it is real, it’s not. Even if the Mock works fine, it doesn’t mean that the real service will. It also means that it will not provide real functionality, even if it looks like it might. Manage expectations; when first faced with a well done Mock, it’s common to think it’s close to a proper service.
What are the Best Practices of Mocking?
The drawbacks above aside, Mocking is extremely powerful used correctly, and can save a lot of time and money for you. We’ve compiled some of our favorite Best Practices here for you to have in mind when creating Mocks.
Start small and expand.
A very simple rule of thumb is: Your First Mock should be available within hours of starting to build it. This rule is useful since it forces you to move quickly and focus on a simple deliverable, which you probably will find surprisingly useful but not quite good enough. Next step then would be to examine what’s needed to expand for creating good tests.
Try using an iterative process; add enough functionality to create the next set of tests, create them, evaluate your needs and then move into the next iteration. You will find as you move along that how critical the next batch of functionality to add in the Mock will be less and less critical and the cost for adding it will be higher and higher. Somewhere along the line is the perfect trade off of functionality and cost.
Only Deep Mock what you need to Deep Mock.
Another successful approach is choosing what to mock in depth. Some interfaces might be less complex or have less business value, making it less important to Mock in Depth, while other might be the opposite. Having limited resources, a good approach would be to focus your mocking effort on the interfaces where testing might be more complex. Set up your own set of deciding factors to decide on the depth necessary; some might be Frequency of use, Complexity, Accessibility, Business Value.
Agree on what the scope is and how “real” it should be
To get your mocking project of to a good start, it’s always a good idea to get a buy in from all stakeholders and agree on how detailed the Mock should be. The answer is not binary; it doesn’t have to be either or; it could and should be somewhere in between; to create a mock that’s to lightweight equals test that are to lightweight; a Mock to heavy equal cost. Instead, look at factors like Frequency of Use, Complexity, Accessibility and Business Value and figure out a level of mocking and get a commitment for the scope.
Think of reuse
We said earlier that mocks often are discarded after use, which in many cases is suboptimal; there are many scenarios where the Mock actually is useful; where the people involved needed the Mock where the live service was not accessible. Real world example; a member in our community used the Mock as a selling tool. The sales staff brought a soapUI Mock on their lap tops out to prospects; showed the service mock as an example of the real live service and then showed web page looking like the prospect’s web site consuming the Mock as an example of the value the company could deliver. This was extremely successful, and with a very low investment since the Mock was already made for the implementation project and the web page could be created in a matter of hours. So the take away is; the Mock can be reused in many levels; by you, by your company, but also by customers and partners.
Get a buy in.
Once you’ve formed an idea of what your mock should be, work on getting an agreement with all stakeholders. This will make your life easier later on in the project. If your stakeholders agree on how deep the Mock should be and what to expect from it, things will run so much smoother. This could include a full scale simulation of the real thing, but it could also be that you will not get what could be seen as lifelike behavior.
Go deep. Really deep!
One thing that should be considered is creating good and reliable Mocks of subsystems. Maybe you have a sub system that will be hard to access during the development of tests or even during tests. These sub systems are usually vulnerable sub systems or sub systems that contains sensitive information. If you come across one of these; don’t hesitate, this is a prime candidate for Mocking. It will help you decouple that system during test creation or even development.
Note that this type of mock is just not for testing, but also very useful for development. This means -whether you dear reader is a developer or a tester, this is your time for cross competence cooperation- you have a lot of gains across the board. Cut through the red tape, create a creative workaround, and cooperate in order to calm the quails of domain cross communication (Translation: If you work together it’s easier to bypass the fact that it’s hard to access systems on other sub networks).
Consider the cloud
Sometimes you might be in a situation where the local hardware test resources might not be enough; you might not be able to scrounge up a server to place your Mock for several people accessing it. You might not have access to a server, or you might have access to it, but aren’t allowed to place your Mock there without navigating through a complicated process, or you might just not find one that is placed where everybody that would need access to it will get access to it because of network security.
Enter the cloud! There are many services available where you set up a virtual server in the cloud. These will of course be for pay, but the costs for the pay-as-you-go plans are surprisingly small; Amazon even has got a service that is free. The levels of free data transfers are not particularly large, but could be sufficient for your Mocking needs, look into it. In general the cloud services are very easy to set up and use and your technical level doesn’t need to be particularly high, so it’s a very viable option.
This best practice is a bit unorthodox, and we don’t take it lightly, but believe us, this one works... If we’ve recommended a careful approach to mocking previously, this is the opposite.
If you have identified the need for Mocking and your management doesn’t give you the resources or time; Go Skunk! Create a mini Skunk works where you create the Mock in secret. Sometimes it just might be too complicated to get the approval through the proper channels in which case we recommend using some of the time you have for other tasks to create a Mock in secret; Mocking will save you time later so the Skunk Mock will probably not show up in the bottom line anyway. If you place it in a free instance of the Amazon Cloud, the Mock will not even be in the company network.
This might be practices in the grey zone, but you know what? Loyalty to your organization might need some clandestine activities (as long as your priorities are straight); the benefits of your secret work will help the organization and advance it. Just be sure of security and make sure no sensitive information leaks out. Also make sure the Mock is of the correct size, don’t overmock.
WAR, What’s it good for?
One Major feature in soapUI is the ability to export your mock as a WAR file. This makes it possible to deploy it in any Java server environment, running the Mock standalone without soapUI. Why should you do this? This is a very simple, but good way of either testing your network and live environment or to make your Mock available for your team.
A Web Service Mock is very easy to create and since the format of a Mock Service is pretty stringent, very easy to expand. The WSDL is a very clear service specification which makes it possible to auto generate the initial Mock automatically; a feature that’s available in soapUI.
Also a Web Service has a handful of Interfaces that are critical and a number that aren’t, making it easy to choose which Interfaces to focus on. Since it’s just text or data, the overhead for the mock is not very large, meaning Service Mocking has very low overhead and creating mocks in a primitive fashion very viable.
This makes Web Services, or most service standards, very easy to mock.