It can't hurt to use a Virt
Often when working on a sprint team as a tester for an API service you find yourself waiting for new functionality to be added before you can start creating your test. How cool would it be if you could start creating and testing different scenarios before your developers finish programming the service?
What happens when you're testing an application that requires a third-party API that charges you money every time you make a request to it? How do you test if a third-part service goes down to see how your application reacts? How do you test edge cases for APIs?
How ServiceV can help you with API testing
In my TestTalks interview with Paul Bruce, Paul shares all the benefits of Service Virtualization, including the ways in which it can help us test our APIs with their ServiceV tool.
For those of you that don't know, Service Visualization is essentially an approach to emulating behaviors or components in a larger system. Think of it as a way to emulate your APIs without actually hitting your APIs. It's really helpful for testing things like what happens if a service is down, or for negative testing — like if you need to test some HTTPS status codes returned by your service when something is wrong.
What you can do with ServiceV
For example, my team is required to test destructive things, like what happens when the database is offline or a service is down. If we were to run these test in parallel in our CI environment, it would affect any other tests that might be running at the same time. As a result, most of these types of tests are manual, which adds extra time to our testing efforts.
Additionally, many of our tests are not automated because they involve many manual interactions that are not easy to automate to get the service in the specified condition we want to test.
ServiceV helps you test third-party APIs that might have a limit to the amount of transactions they can receive in a day, or to the number of requests they allow in a certain time frame — like many of Twitter's REST APIs.
See ServiceV in action
After speaking with Paul, I thought it would be a good idea to create a short video on how to create a simple Virtual Service and show you how easy it is to get started with and use.
Hopefully, this will also give you an idea of the types of things it can help you with on your API testing projects.
Example of ReadyAPI ServiceV in Action
- First, create a REST test that calls Google Books: https://www.googleapis.com/books/v1/volumes?q=turing
- Run the test
- Copy the JSON returned
- Right click on the project and select Generate Virt
- Under the ServiceV tab, click on Virt, then under the Outgoing, click on + add response
- Name the response Normal
- Under the Normal response section, select Http Status Code 200 – Ok
- Select Content | Media type: application/json
- Paste the response that we copied from our test
- Change the author name of the first element to Joe Colantonio
- Click on the Start Button to start the Virt Server
- Click on the SoapUI tab
- Click on the books request
- Under Endpoint, select the name of the endpoint for your Virt server that you just created
- Click Run to run the test
- Notice that under authors it returned Joe Colantonio, so we know it's our local copy
- Under Endpoint, select the normal https://www.googleapis.com URL and run again
- Notice that it returns the Alan Turing — not our local copy
Quick taste of ServiceV
Now, this is a trivial example, but even with this simplicity think of the power and possibilities, it affords you.
You can now start to create your tests before developers have a working service. Also say you have a third party dependency that charges you every time you use their service—now worries. You can use a Virt to easily mock the response and use only the real third party during official QA.
Discover More
To discover even more Service Virtualization automation goodness listen to my TestTalks interview with Paul Bruce or read the entire transcript here.
