With a testplan in hand, it's time for execution. These are regression tests, so I should spend the time now to automate them and save manual execution time on subsequent runs. But how should I perform this automation?

In a past co-op term I used SoapUI for similar testing, and I'll use it again here. It provides a nice GUI for creating sequences of network calls, running them and making assertions against the responses. And importantly for me, the trial version has no expiration date and loses very few features relative to the paid version.

There are two basic steps to creating tests in SoapUI. First, you create "Resources," a hierarchy of endpoints and the network calls to those endpoints. Then, you put those calls in sequence and add assertions to create a Test Case. In-between network calls you can add additional test steps, such as transferring the value of a parameter or executing a script.

Step 1: Create resources

Notice the segment ${...} in the highlighted line. This specifies a parameter which SoapUI will fill in when the test is executed. In this case SoapUI will look in the current test case for a parameter called "current DAG id," with default value 1. So, if a particular test case needs to access .../2 instead of .../1, I can just set the parameter to 2 within that test case instead of creating another global resource.

Step 2: Put resources into test cases

This image is a bit dense, so let's unpack it. In the left column I have a Test Suite named "Regression," containing several Test Cases. In the expanded test case you can see my Test Steps, which in this case are a bunch of POST requests. On the right side are the details of one POST request. At the bottom right are a pair of assertions, which are how SoapUI judges whether this particular test step passed or failed.

And that's about all there is to it. In the next journal entry, we'll look at the results of these tests, including the bugs they turned up.