Building an API: Test Harness UI

On the project I’ve been working on we’re building an API to be used by other applications in the organisation but when we started none of those applications were ready to integrate with us and therefore drive the API design.

Initially we tried driving the API through integration style tests but we realised that taking this approach made it quite difficult for us to imagine how an application would use it.

It also meant that we didn’t have a good way to show our business stakeholders the work we’d done – showing off pieces of JSON going back and forth probably wouldn’t have gone down too well!

We therefore decided to create our own test harness UI which we would use to show case what we’d developed so far and also use to help drive the design of the API.

Obviously it would be better if we were able to drive the API out from a real application but given that wasn’t possible the test harness approach seems to work reasonably well.

The main problem that we ran into was not knowing how much effort we should be putting into the test harness UI given that its primary purpose was to show the progress being made on the UI.

We started out not writing many tests or paying much attention to how it looked since it was assumed to be a throwaway UI.

Over time it’s become more complicated and since we use it to display progress to management stakeholders we’ve spent time making it more presentable.

Despite that I’d still say the effort we’ve put in is worthwhile because it gives us a way to show progress to non technical people.

From my experience if you can’t do that they’ll start to get nervous and wonder if you know what you’re doing which isn’t a good place to be!