AUTOMATION 10 - API checking #2, further down the rabbit hole

Last time we took an initial look at API's and how to do simple checks with them.

Today we're going to continue to look at our sample application, SimpleBank, and come up with some more checks we can do which will explore more what you can do.

In most API checking tools, you can daisy chain a number of requests together, and perform an assertion on it.  We were doing this in a way before, when we'd do an initial load of credit onto an account, and we'd expect to see the TransactionSuccess field return as 1 or True.

Ideally with any automated check you want the system to have an expected return, and to check the system response against that pre-programmed and expected.  Soap UI, in line with JUnit calls any check which results in either a pass or a fail interpretation as an assertion.

Use of assertions allows you to run a huge volume of checks, but you only have to worry a human being about the ones which come out different as expected.

This is in essence the basis of our First Iron Law of automation,

If you rely on a human interpreting everything, you've got yourself a nice aid for testing, but you're not really embracing the power of automation.  You've got a superfast machine, that relies on human interpretation.  Worse still, you're tying up time of a human operator who could be better used doing manual exploratory testing.

Add-in another API tool layer

Last time we'd replaced our inter-bank service with an API tool layer we could drive our checking from.

Today we're going to simplify it a bit more, because it's only really the service layer and below we're interested in checking...

This time we've added another API tool substitution which replaces the internet banking service.  Here we're again interested in only one function today, BankBalance, which looks like,

Where,

• BankAccount is the account number we want the balance of

Where,

• TotalBalance is the balance of the account requested (negative if overdrawn).
• FailCode returns 0 if account number was found, else 888

We now have the potential to run some more interesting checks on our system combining last time's BankTransaction call with today's BankBalance call.

Most importantly, we can do what Soap UI calls "property transfer" or using the response from one function elsewhere.

I'm going to specify two such scripts, which use a combination of these API calls, together with transferring values.

Check 1:  Apply a credit

This is what you can put together as a scenarios to be automatically checked,

1. Call BankBalance for account number 2938449.  Store the TotalBalance response as variable oldBalance.  Assert that FailCode is 0. (ie account found)
2. Call BankTransaction for account number 2938449, applying a $20 credit.  Assert that FailCode in the response if 0. (ie transaction applied)
3. Call BankBalance for account number 2938449.  Store the TotalBalance response as variable newBalance.  Assert that FailCode is 0. (ie account found)
4. Assert that newBalance = oldBalance + 20

If any of these assertions is not true, the script will fail, and alert the user.

Check 2:  Apply a debit

This is what you can put together as a scenarios to be automatically checked,

1. Call BankBalance for account number 2938449.  Store the TotalBalance response as variable oldBalance.  Assert that FailCode is 0. (ie account found)
2. Call BankTransaction for account number 2938449, applying a $15 debit.  Assert that FailCode in the response if 0. (ie transaction applied)
3. Call BankBalance for account number 2938449.  Store the TotalBalance response as variable newBalance.  Assert that FailCode is 0. (ie account found)
4. Assert that newBalance = oldBalance - 15

If any of these assertions is not true, the script will fail, and alert the user.



Again, you don't have to feel absolutely comfortable writing all that up in Soap UI - look back to our series on automation as a service.  The person who writes these kind of scripts we defined as the automator ...

Maybe you're really technical, and you're comfortable doing this - that's great.

But don't forget we separately defined the role tester, and their role was important too,

An important part of the tester role in automation was being able to specify a good script that could be automated.  We essentially did that both today and yesterday.  However today we did it without using any pseudo-code, and that's okay as long as our intended sequence is totally clear.