AUTOMATION 9 - API checking, introducing the basics

Previously we were looking at unit checking using frameworks such as Junit - they allowed us to perform very rapid testing on a small component.  Today we're widening our scope looking at API automation tools.

Now I really don't want to seem to be old, but back when I started programming as a kid, most "systems" we programmed were a single application/program.

These days, much more common are multilayered architecture for any solution.  Each layer is a specialised application which deals with a specific aspect of the system - you might hear of service level architecture or SOA to explain this.

These different layers communicate to become "one system" through API or application programming interface protocols.  Before you know it, you've created a monster ...

Let's consider a simplified bank, SimpleBank ...

Lets start from the bottom and work up, as with most multi-layered architectures.  Typically in such structures, your bottom is your most secure layer, which contains your data, and your top layer is how everyone accesses it.

• Data access layer - this is the database, which keeps record of customer details, individual transactions, balance.
• Business layer - this one works out thing such as interest, works out if you have enough in your balance to pay a payment request and then debit your balance, applies a credit to your account etc.  It's essentially where all the bank's business rules are applied linking requests from the service layer to records from the data access layer
• Service layer - here the requests from all the different interfaces to be processed are managed.
• Payment gateway - this is where payment requests (EFTPOS in NZ) are recieved from
• ATM - where balance and withdraw cash requests come from
• Internet banking - where balance, transaction details and payment requests can be sent from
• Inter-bank connection - where once an hour credits are received from other banks, and payments sent out to other banks.

I've worked on similar systems, and believe me, they can get scary.  How do you get such a complex system into a test environment to test?  For instance, I've only done one project where the "inter-bank connection" was actually connected to other banks - because think about it, that means you need another bank's complete application linked/part of your own test environment.

API tools allow us to select a point in a system, send mock messages to the incomplete environment, allowing us to mimic a completed environment.  We're able to run our checks against a much more completed system than in our unit tests previously, where the checks were run only against each code component.

All that might sound confusing, especially if you're new.  Which is why we're going to explore it with an example.

So take our simplified bank - we want to test the bank system really from the service layer down.  As we said, we don't have inter-bank connections to replicate other banks in our system, so we'll need to mock that as a service.

Now between the inter-bank and service layer there is only really one key message we're going to worry about in this series, BankTransaction, which allows flows of money to and from SimpleBank.  This inward message (to SimpleBank) looks like this in our tool,

Where,

• BankAccount is the bank account number of the relevant SimpleBank customer for whom the transaction applies.
• CashAmount is the amount of money involved
• TransactionType is either CREDIT or DEBIT.

Once received and processed, there is a response send back,

Where,

• TransactionSuccess indicates if it was applied alright, 1 for success, 0 for a fail
• FailCode if the transaction fails, it provides a code to give more information

Typically within most API automation tools, you can configure a suite of API call checks, and determine the set responses you want.

Let's test some simple business rules at SimpleBank

Here are some basics we'll check today.  At SimpleBank, all bank credits and debits are applied immediately, with no clearing time at all!

However customers are limited to being able to withdraw more than $1000 a day (that's NZD - not that it really matters, but I'm a Kiwi).  If you break this, you get an 888 fail code.

Scenario 1: Maximum withdrawl

Pretty simple and obvious, but we'll first apply a credit of $1010 dollars, then withdraw $1000.  This should go though (only just).

Scenario 2: Withdrawing too much

Don't we love testing a boundary - so this time is the same as the above scenario, but this time we try and take out $1001, which should fail.

Scenario 3 - lots of transactions

A favourite check of mine.  Give an account $1010 as before, then try two $500 withdrawls, followed by a $1 one.  The first two should clear, the third should cause an error code of 888.

Scenario 4 - I can spend more money tomorrow

Not everything is suitable to automate.  Are you thinking of a check which sees it you can spend more tomorrow if you've already spent $1000?

This is actually a bad choice of check to use the API for.  We can't control the time, so it would be a 25 hour test.  Would be better as a unit test, if we can mimic a change in time, or alternatively as a manual test.  But a test which takes so long to run, esp when it's past of a suite of tests, isn't great.

Next time

We'll be looking at more in depth things we can do with such tools in our SimpleBank example.  We will then round out looking at API's by asking that question "I'm not technical, how much do I need to know?".

If this is worrying you, look at our scenarios 1-4, and realise at their core, they are just sensible scenarios we'd want to do manually.  It's just we're using a mechanism.  We don't always have to understand the mechanism as testers, but we do need to know what makes for a good check.

But that's in the future, and ...

Extension material

I've been reacquainting myself with SoapUI for this series, and noticed after 3 years, some of it has changed.  So I will be avoiding slaving myself to the how-to's of just that tool.  The aim of this series is an introduction to the concepts and thinking about what makes good checks.

You can download SoapUI here and play around with the sample API service to get the feel.  There is a great series of instructions here, including installing, setting up your first project and some of the useful features.  SoapUI also have an introduction to testing API's here.

As Lisa Crispin mentioned, you might want to try out other tools - so Google around.

If you want to delve more into the theory of API web services, Katrina Clokie has a useful article here which collects resources she's found useful.