[Crazy Go Day] Simple Golang Unit Test Implementation

Implement really simple test

Den Chen
4 min readApr 1, 2022

Overview

Dcard

Hi there !! Recently I am preparing for the backend internship of Dcard, and this series of articles (Crazy Go Day) are some development skills I learned during this period of time :)

Last article we discuss about why I choose to use Gin for my backend framework. Today, we are going to continue with a important part of developing backend service — Unit testing !

Why we need unit tests?

Imagine that you are a hard-working backend engineer who spend day and night programming in order to complete a complicated API services. Finally, you finish it and it remains to test whether your service works properly. Then, you spent another day and night doing manually testing with curl command…

That sounds exhausted right ? And for each tiny modification asked by manager, you will need to do all the tests MANUALLY again :(

That is the reason why unit tests is invented. Unit tests are responsible for service quality, and the more detailed tests we have, the more stable the quality is ! What’s better, no matter you execute unit tests on your machine or insert them into CI/CD process, it saves time compares to doing everything manually.

How does unit tests working in Golang

Fortunately, as a modern high level language, golang is natively support unit tests, which really surprise me a year ago :)

The concept is quit simple, naming your testing file with end of _test.go , and execute go test -v <directory path> under your file directory.

Beside, what’s more fascinating , golang has native library called test that provide some useful tool like assert for you ! (No need to install it !)

My implementation in this project

I implement three kinds of unit tests this time:

  • success_test.go testing whether each services works properly
  • error_test.go responsible for error handling testing
  • cache_test.go test whether cache works properly

Now, let’s dig into the code~

~~Success tests~~

Testing create url entity

First, I send a POST request to my server, and check whether the server response the thing I want.

I use assert.Equal to check each field value existence and also checking the short url format correctness.

Then, I test whether the short url redirect to the right target. This is a bit complicated since we need to check the request location BEFORE it redirect, so I stop the request redirection process by using the code between line 26~31 .

Let’s explain the handler function CheckRedirect first. It takes two input parameters: req and via , and req represent the next request entity while via represent an array of passed requests. Besides, if we return nil , this handler function won’t effect the redirection process flow. But if we return ErrUseLastResponse , the redirection process will end in this step and return the last response.

Since I found that the redirection process will start a 301 redirection first before doing the 302 redirection, I skip the first one by judging whether len(via) > 1 .

Finally I get the location header of 302 request , and I check whether the location field in header meets our target url.

~~Error tests~~

For error tests in this project, I only test the createurl api to see whether the error handling works well.

First, I create an expiration time that is one hour before current time, which is invalid.

Then, I send a POST request with this invalid expiration time body, and check whether my server return the right ErrorCode and StatusCode .

~~Cache tests~~

In my cache unit test, I only test one cache function: Handling the invalid access.

First, I random generate a id which does not exist in database.

Then, I send the first request to my server. Since this is the first time my server meet this request, it will still query the database to check whether this url exist or not. i just simply check if my controller handle this properly.

Since the return ErrorCode by my cache is different from the ErrorCode return from my controller, I can use this to distinguish the response origin.

Finally, I send the second same request and check the ErrorCode .

Congrats guys !!! We now have basic understanding of unit testing and also try out some implementations lol.

Thank you for your time reading. Any suggestions are welcomed and feel free to point me out if anything is unclear.
See u guys next time! (Happy coding~

--

--

Den Chen

NYCU CS/AM | Crazy coder | Enjoy the time creating new stuff!