Continue from the previous topic…
Unit Testing is a level of automated software testing that units which can be modular parts of the program are tested. Normally, the “unit” refers to a function, but it doesn’t necessary always be so. A unit typically takes in data and returns an output. Correspondingly, a unit test case passes data into the unit and check the resultant output to see if they meet the expectations.
Unit Testing Files
In Golang, unit test cases are written in <module>_test.go files, grouped according to their functionality. In our case, when we do unit testing for the videos web services, we will have the unit test cases written in video_test.go. Also, the test files need to be in the same package as tested functions.
Necessary Packages
In the beginning, we need to import the “testing” package. In each of our unit test function, we will take in a parameter t which is a pointer to testing.T struct. It is the main struct that we will be using to call out any failure or error.
In our code video_test.go, we use only the function Error in testing.T to log the errors and to mark the test function fails. In fact, Error function is a convenient function in the package that combines calling of Log function and then the Fail function. The Fail function marks the test case has failed but it still allows the execution of the rest of the test case. There is another similar function called FailNow. The FailNow function is stricter and exits the test case once it’s encountered. So, if FailNow function is what you need, you have to call the Fatal function which is another convenient function that combines Log and FailNow instead of the Error function.
Besides the “testing” package, there is another package that we need in order to do unit testing for Golang web applications. It is the “net/http/httptest” package. It allows us to use the client functions of the “net/http” package to send an HTTP request and capturing the HTTP response.
Test Doubles, Mock, and Dependency Injection
Before proceeding to writing unit test functions, we need to get ready with Test Doubles. Test Double is a generic term for any case where we replace a production object for testing purposes. There are several different types of Test Double, of which a Mock is one. Using Test Doubles helps making the unit test cases more independent.
In video_test.go, we apply the Dependency Injection in the design of Test Doubles. Dependency Injection is a design pattern that decouples the layer dependencies in our program. This is done through passing a dependency to the called object, structure, or function. This dependency is used to perform the action instead of the object, structure, or function.
Currently, the handleVideoRequests handler function uses a global sql.DB struct to open a database connection to our PostgreSQL database to perform the CRUD. For unit testing, we should not depend on database connection so much and thus the dependency on sql.DB should be removed. The dependency on sql.DB then should be injected into the process flow from the main program.
To do so, firstly, we need to introduce a new interface called IVideo.
type IVideo interface {
GetVideo(userID string, id int) (err error)
GetAllVideos(userID string) (videos []Video, err error)
CreateVideo(userID string) (err error)
UpdateVideo(userID string) (err error)
DeleteVideo() (err error)
}
Secondly, we make our Video struct to implement the new interface and let one of the fields in the Video struct a pointer to sql.DB. Unlike in C#, we have to specify which interface the class is implementing, in Golang, as long as the Video struct implements all the methods that IVideo has (which is already does), then Video struct is implementing the IVideo interface. So now our Video struct looks as following.
type Video struct {
Db *sql.DB
ID int `json:"id"`
Name string `json:"videoTitle"`
URL string `json:"url"`
YoutubeVideoID string `json:"youtubeVideoId"`
}
As you can see, we added a new field called Db which is a pointer to sql.DB.
Now, we can create a Test Double called FakeVideo which implements IVideo interface to be used in unit testing.
// FakeVideo is a record of favourite video for unit test
type FakeVideo struct {
ID int `json:"id"`
Name string `json:"videoTitle"`
URL string `json:"url"`
YoutubeVideoID string `json:"youtubeVideoId"`
CreatedBy string `json:"createdBy"`
}
// GetVideo returns one single video record based on id
func (video *FakeVideo) GetVideo(userID string, id int) (err error) {
jsonFile, err := os.Open("testdata/fake_videos.json")
if err != nil {
return
}
defer jsonFile.Close()
jsonData, err := ioutil.ReadAll(jsonFile)
if err != nil {
return
}
var fakeVideos []FakeVideo
json.Unmarshal(jsonData, &fakeVideos)
for _, fakeVideo := range fakeVideos {
if fakeVideo.ID == id && fakeVideo.CreatedBy == userID {
video.ID = fakeVideo.ID
video.Name = fakeVideo.Name
video.URL = fakeVideo.URL
video.YoutubeVideoID = fakeVideo.YoutubeVideoID
return
}
}
err = errors.New("no corresponding video found")
return
}
...
So instead of reading the info from the PostgreSQL database, we read mock data from a JSON file which is stored in testdata folder. The testdata folder is a special folder where Golang will ignores when it builds the project. Hence, with this folder, we can easily read our test data from JSON file fake_videos.json through relative path from video_test.go.
Since now the Video struct is updated, we need to update our handleVideoAPIRequests method to be as follows.
func handleVideoAPIRequests(video models.IVideo) http.HandlerFunc {
return func(writer http.ResponseWriter, request *http.Request) {
var err error
...
switch request.Method {
case "GET":
err = handleVideoAPIGet(writer, request, video, user)
case "POST":
err = handleVideoAPIPost(writer, request, video, user)
case "PUT":
err = handleVideoAPIPut(writer, request, video, user)
case "DELETE":
err = handleVideoAPIDelete(writer, request, video, user)
}
if err != nil {
util.CheckError(err)
return
}
}
}
So now we pass an instance of the Video struct directly into the handleVideoAPIRequests. The various Video methods will use the sql.DB that is a field in the struct instead. At this point of time, handleVideoAPIRequests no longer follows the ServeHTTP method signature and is no longer a handler function.
Thus, in the main function, instead of attaching a handler function to the URL, we call the handleVideoAPIRequests function as follows.
func main() {
...
mux.HandleFunc("/api/video/",
handleRequestWithLog(handleVideoAPIRequests(&models.Video{Db: db})))
...
}
Writing Unit Test Cases for Web Services
Now we are good to write unit test cases in video_test.go. Instead of passing a Video struct like in server.go, this time we pass in the FakeVideo struct, as highlighted in one of the test cases below.
func TestHandleGetAllVideos(t *testing.T) {
mux = http.NewServeMux()
mux.HandleFunc("/api/video/", handleVideoAPIRequests(&models.FakeVideo{}))
writer = httptest.NewRecorder()
request, _ := http.NewRequest("GET", "/api/video/", nil)
mux.ServeHTTP(writer, request)
if writer.Code != 200 {
t.Errorf("Response code is %v", writer.Code)
}
var videos []models.Video
json.Unmarshal(writer.Body.Bytes(), &videos)
if len(videos) != 2 {
t.Errorf("The list of videos is retrieved wrongly")
}
}
By doing this, instead of fetching videos from the PostgreSQL database, now it will get from the fake_videos.json in testdata.
Testing with Mock User Info
Now, since we have implemented user authentication, how do we make it works in unit testing also. To do so, in auth.go, we introduce a flag called isTesting which is false as follows.
// This flag is for the use of unit testing to do fake login
var isTesting bool
Then in the TestMain function, which is provided in testing package to do setup or teardown, we will set this to be true.
So how do we use this information? In auth.go, there is this function profileFromSession which retrieves the Google user information stored in the session. For unit testing, we won’t have this kind of user information. Hence, we need to mock this data too as shown below.
if isTesting {
return &Profile{
ID: "154226945598527500122",
DisplayName: "Chun Lin",
ImageURL: "https://avatars1.githubusercontent.com/u/8535306?s=460&v=4",
}
}
With this, then we can test whether the functions, for example, are retrieving correct videos of the specified user.
Running Unit Test Locally and on Azure DevOps
Finally, to run the test cases, we simply use the command below.
go test -v
Alternatively, Visual Studio Code allows us to run specified test case by clicking on the “Run Test” link above the test case.
We can then continue to add the testing as one of the steps in Azure DevOps Build pipeline, as shown below.
By doing this, if any of the test cases fails, there won’t be a build made and thus our system becomes more stable now.
cuteprogramming 