AUTOMATION 11 - API use #3, through the looking glass

Previously we've been looking at ways we can use APIs to aid our scripted automated testing.  There are two additional ways APIs can be helpful which I want to cover.

The first, using them to perform load tests, I'll cover much later in this series.

The second, using them to aid manual testing, will be our focus today, and really be a little off-road from the them of automated checking scripts, but worth covering for completeness.

Thus in our series on APIs  we've been talking about the architecture at our example institution, SimpleBank,

With the testing we're doing, we've been taking a top-down approach.  Replacing a module at the top with an API call, and using it to drive the behaviour of our system, and compare it against expectations.  Pretty much like the ultimate remote control of the bank systems.

It's a pretty important approach.  Unlike unit checking, more of your system is being checked - your system under test resembles more that of your final system than with unit testing.  And yet you'r avoiding a lot of overhead of sending complete web pages of information back and forward across a connection.  Sending requests is pretty light work as we've seen from our example API calls.

However we can also choose a bottom up approach.  Let's say for example that we're radically reworking the internet banking function, and it's going to take a while to redesign the pages.  This modification will also change the API calls on which the pages are dependent - so we can't test until both are done?

API tools allow you to run a mock service,

This allows you to fool your web project that it's connected to a banking system.  When your internet banking application makes a call, your API tool will return a predefined response, "a mock reply".  You set up in your API tool a series of mock calls, which will typically always return the same response for a function call (although you can customise them a little).

Hence for instance, you can do a balance request, commit a payment transaction, then check your balance again (which is static and unchanged).  Your balance always returns the same number you've defined when you set up the mock service.

The focus here isn't on the change of numbers, but that entering your data, and pressing buttons, the requests are fulfilled as expected, and it doesn't fall over in the browser side.  This should make for less problems once you do link your new internet banking pages with the modified back end, because you'll have removed obvious problems easy.


Extension material

Find out more about setting up mock services in Soap UI here.