When we typically talk about how API call limits constrain the development process, our main concerns are performance and load testing, which can place a tremendous load on back-end services. But paid services can come with such stringent limits that they also affect the kinds of unit testing required to assess basic application logic.
For example, the internal development group at CA Technologies, called GIS, found itself struggling to test and validate internal applications for master data management that relied on a service from Dun and Bradstreet. The new application was responsible for cleaning and enriching customer data as it was input into its SAP system. This made it easy to automatically enter address and credit information.
But the development team ran into problems with the limited number of calls they were allowed to make into the D&B service. The development group was allowed just 30 calls into the API per month.
A Way Around Tight Limits
The limits didn’t just affect performance testing. They also were an impediment to the unit testing required to ensure that the application logic worked as intended and that the right data was being captured and loaded into the correct fields.
Deven Shah, senior IT director at CA, says, “A lot of times during testing, the service was available intermittently. For a few days, it was not available at all for development and testing. We had to make sure it was available all of the time. Service Virtualization helped us build our way around the virtual service to get to the service all of the time from a development and test perspective.”
By eliminating the constraint of limited access, the team was able to reduce the development time by about 10 days from a six-week development cycle.
“When we had that limit around testing, we would test it once or twice and hope that it worked in production,” says Shah. “We coded the application around that, expecting that it would work. When we tested it when it became available, we discovered we needed some rework because the application was not tested continuously.”
Stubs Only Leave You Testing the Test Device
Initially, the development group had looked at using stubs to try and simulate the back-end D&B service. The problem with stubs, though, was that they took a lot of time to develop and maintain. Furthermore, they had to be rewritten every time the D&B service changed. The development time ended up spending a lot of time doing development outside the scope of the application.
“We could potentially reuse the stub,” Shah said, “but with every new release we needed to make sure the stub was tested as well. If you are doing unit testing against that stub, you need to make sure the stub is returning what it is supposed to, and we would update it as needed.”
CA found it would take about three to four days to mirror the service exactly, while a virtual service took less than a half-day of work. Using CA’s own Service Virtualization tool, LISA, it took about two hours for one person to capture enough packets from communications with the service to generate sample data. It took another couple of hours to build a virtual service based on these parameters.
In contrast, they found that it would take a developer a couple of days to code the stub, followed by a few more to test it. Now, with Service Virtualization, Shah’s team is able to achieve the same result with far less effort.