Backend development in Golang — REST API testing (Part 1)

Unit testing involves isolating our source code to ensure they behave as expected. Integration testing, on the other hand, is to ensure all parts of our software work well with each other.

In backend development, integration testing can prove to be very useful, even more so than unit testing. I recently read somewhere that, as software companies, we are not paid for our code — we are paid for the value we provide.

Take for instance, you built a system that helps a company manage their operations, especially in the area of payroll management. Which is more important to the client — A, a function that takes in a file and returns the filename — or B, an API endpoint to upload a file and get a desired report as output? You would agree with me that while A is a vital feature, the client truly cares more about B.

Why then do some developers write elaborate unit tests but leave holes in the general service resulting in numerous bug reports? Would it not be better to operate the 20/80 principle here — spend 80% of testing efforts on the service in general, and 20% testing whether the capitalization function works as expected?

I am convinced you will sleep better at night if you are certain that if your API consumers make a certain request, they will get a certain report as intended.

While the term integration test may not fully capture what I’m proposing (some have used service testing, backend testing, et cetera), it is meant to convey the fact that you test your services as though the end user is using them, though not as far as user testing, and not as close as merely testing code. You are testing, for example, what happens if a user sends a POST request on a certain resource. In this, you try, as closely as possible, to simulate real API consumer actions on your service.

From the image above, testing our service implies we replicate what an actual client request does. That is, from the instantiation of the DB (for an actual client that would be reusing a connection from a pool or copying an instance) to response, we simulate a proper endpoint cycle.

In the next part of this series, I will demonstrate with an example, how the service testing can be carried out. We will be building a small API service, BizNet, that stores records of the operations of a business. After establishing the simple code base, we will test all the endpoints, and see how we can ensure that expected user requests give expected responses.

An added advantage is that our tests can also serve as documentation for how the API clients should make requests and handle responses.

Thank you for reading, share this with your friends and colleagues who might need it, and stay tuned for the next part.