When programming, there are times when you need to check if any code works correctly.
For an API server, you can test it directly by making calls, and for specific programs, by pressing buttons.
However, as the layers deepen and the relationships between the data increase, it can become more challenging to test.
For example, let’s assume you have data with the following relationships:
And the interface looks like this:
type CommentService interface {
CreateComment (ctx context.Context, postingID int, request CreateCommentRequest) (CreateCommentResponse, error)
}
In this case, to verify if a comment is created correctly, you would have to follow these steps:
- Create a user.
- Create a post.
- Create a comment.
- Check the data stored in the DB.
These tasks can definitely be done, but if you have to perform them every time you write a function, the amount of context you need to understand increases, making it progressively harder to conduct tests as the relationships get more complex.
This is where unit testing comes in.
Unit Testing
As the name suggests, unit tests are about testing individual units of code. It verifies whether a specific unit of code functions as intended.
Defined simply, it’s the process of testing the smallest functional unit of code.
Here, the functional unit can take various forms, but typically, testing is carried out at the function level.
Let’s assume the internal flow of the CreateComment function is as follows:
sequenceDiagram
CommentHandler ->> CommentService: postingId, request
CommentService ->> PostingRepository: ExistsByID
PostingRepository -->> CommentService: true
CommentService ->> CommentRepository: CreateComment
CommentRepository -->> CommentService: commentID
CommentService -->> CommentHandler: commentID
In code, it might look like this:
func (c *CommentService) CreateComment(ctx context.Context, postingID int, request CreateCommentRequest) (CreateCommentResponse, error) {
exists, err := c.postingRepository.ExistsByID(ctx, postingID)
if err != nil {
return CreateCommentResponse{}, err
}
if !exists {
return CreateCommentResponse{}, errors.New("posting not found")
}
commentID, err := c.CommentRepository.CreateComment(ctx, request.ToComment())
if err != nil {
return CreateCommentResponse{}, err
}
return CreateCommentResponse{CommentID: commentID}, nil
}
Selecting Unit Test Targets
So what are the code targets that need to be tested in this function?
exists, err := c.postingRepository.ExistsByID(ctx, postingID)
if err != nil {
return CreateCommentResponse{}, err
}
if !exists {
return CreateCommentResponse{}, errors.New("posting not found")
}
First, let’s look at the above code. Do we need to test the internal function code of ExistsByID?
No, we don’t. This is because we are testing the CreateComment function, not ExistsByID.
We assume that the error it returns has also been tested in the ExistsByID function and therefore does not branch for a separate test code.
It doesn’t matter if it’s done, but in my case, I simply see it as code for coverage and do not separate it into a distinct test case.
Then someone might ask if we are testing anything related to ExistsByID. The answer is no.
However, we do need to validate that the postingID requested by ExistsByID is correctly passed, and we also need to verify the response value exists since we’re branching based on it.
But doesn’t calling ExistsByID eventually test it?
Yes, you can think that calling ExistsByID also runs its tests.
Using the actual objects will eventually involve calling ExistsByID, accessing the DB, but many testing frameworks in various languages always offer the Mock feature.
Mock
A mock is a fake object that can be used in place of the actual object during testing.
As illustrated above, in a real environment, the commentRepository object is connected to the actual DB, whereas, in the test environment, a fakeCommentRepository object is used to conduct tests.
This concept utilizes polymorphism through interfaces. Just as you can swap objects implemented with PostgresDB for objects implemented with Redis, you can do the same in the test environment.
There are various libraries such as Golang mock, Mockery, but first, let’s explore how to implement and test this code manually without any libraries.
Writing Test Code
Now we have understood the concept of unit test code. It’s time for practical work.
Let’s write the testing code for the CreateComment function mentioned earlier.
First, we create a mock object in the test file.
// comment_service_test.go
type fakePostingRepository struct {
ExistsByIDFunc func(ctx context.Context, postingID int) (bool, error)
}
func (f *fakePostingRepository) ExistsByID(ctx context.Context, postingID int) (bool, error) {
return f.ExistsByIDFunc(ctx, postingID)
}
The reason for adding the function as a struct field is so that when the test code calls it, it can check and return the desired value to be tested.
Next, let’s write the test code for the part below. First, let’s write the test code that checks when the posting does not exist.
exists, err := c.postingRepository.ExistsByID(ctx, postingID)
if err != nil {
return CreateCommentResponse{}, err
}
if !exists {
return CreateCommentResponse{}, errors.New("posting not found")
}
func TestCreateComment(t *testing.T) {
t.Run("posting not found", func(t *testing.T) {
ctx := context.Background()
postingID := 1
request := CreateCommentRequest{
Content: "test",
}
fakePostingRepository := &fakePostingRepository{
ExistsByIDFunc: func(ctx context.Context, postingID int) (bool, error) {
t.Run("ExistsByID Argument Test", func(t *testing.T) {
if postingID != 1 {
t.Error("expected 1 but got", postingID)
}
})
return false, nil
},
}
commentService := &CommentService{
postingRepository: fakePostingRepository,
}
if _, err := commentService.CreateComment(ctx, postingID, request); err == nil {
t.Error("expected error but got nil")
}
})
}
Inside the test code, we initialize the fakePostingRepository and check if the argument postingID enters as intended, which is 1. If it does not, the test is designed to terminate immediately.
Going back to the business logic, aside from the err != nil branch, there are no other significant branches in the remaining code.
Now we proceed to write the success case.
func TestCreateComment(t *testing.T) {
t.Run("success", func(t *testing.T) {
ctx := context.Background()
postingID := 1
request := CreateCommentRequest{
Content: "test",
}
fakePostingRepository := &fakePostingRepository{
ExistsByIDFunc: func(ctx context.Context, postingID int) (bool, error) {
t.Run("ExistsByID Argument Test", func(t *testing.T) {
assert.Equal(t, 1, postingID)
})
return true, nil
},
}
fakeCommentRepository := &fakeCommentRepository{
CreateCommentFunc: func(ctx context.Context, comment Comment) (int, error) {
t.Run("CreateComment Argument Test", func(t *testing.T) {
assert.Equal(t, Comment{Content: request.Content}, comment)
})
return 1, nil
},
}
commentService := &CommentService{
postingRepository: fakePostingRepository,
CommentRepository: fakeCommentRepository,
}
got, err := commentService.CreateComment(ctx, postingID, request);
assert.NoError(t, err)
assert.Equal(t, CreateCommentResponse{CommentID: 1}, got)
})
}
Here I’ve switched to using a library called assert for value checks, which has become almost standard in Go, similar to AssertJ in Java. It can compare using Reflection, making it easy to test pointers as well.
Next, we added CreateCommentFunc, checking the parameters as previously described and mocking the returned commentID as 1.
By writing the test code this way, we can verify the business logic of that function.
It’s not that difficult to write like this, but some issues remain.
If you end up using different repositories, you might find it inconvenient to write such test codes for every file.
Here, you can use the two libraries Golang mock and Mockery, to generate mocked implementations with even more convenience and additional features.
Although the Golang mock is an official Go package, it was archived in 2023 and is no longer maintained, so I wouldn’t particularly recommend it. Mockery, which is managed more actively, is recommended as it has many stars and useful features.
Mockery
Before diving into Mockery, let’s clarify the folder structure. While Mockery is good, its settings can be complex, and care must be taken to set up the packages each time you add it.
The code itself will not change much, but I’ll leave this section in to ensure readers can conduct accurate tests based on this code. If you’re already familiar with it, feel free to skip this section.
// in repository/comment.go
package repository
import "context"
type CommentRepository interface {
CreateComment(ctx context.Context, comment Comment) (int, error)
}
type Comment struct {
Content string
}
// in repository/posting.go
package repository
import "context"
type PostingRepository interface {
ExistsByID(ctx context.Context, id int) (bool, error)
}
// in service/comment.go
package service
import (
"context"
"errors"
"github.com/YangTaeyoung/test-demo-app/repository"
)
type CreateCommentRequest struct {
Content string `json:"content"`
}
func (r CreateCommentRequest) ToComment() repository.Comment {
return repository.Comment{Content: r.Content}
}
type CreateCommentResponse struct {
CommentID int `json:"id"`
}
type CommentService interface {
CreateComment(ctx context.Context, postingID int, request CreateCommentRequest) (CreateCommentResponse, error)
}
type commentSerivce struct {
postingRepository repository.PostingRepository
commentRepository repository.CommentRepository
}
func (c *commentSerivce) CreateComment(ctx context.Context, postingID int, request CreateCommentRequest) (CreateCommentResponse, error) {
exists, err := c.postingRepository.ExistsByID(ctx, postingID)
if err != nil {
return CreateCommentResponse{}, err
}
if !exists {
return CreateCommentResponse{}, errors.New("posting not found")
}
commentID, err := c.commentRepository.CreateComment(ctx, request.ToComment())
if err != nil {
return CreateCommentResponse{}, err
}
return CreateCommentResponse{CommentID: commentID}, nil
}
Next, install the Mockery library using the following command. The version depends on the release, so refer to the releases page.
go install github.com/vektra/mockery/v2@v2.53.0
Then, create a configuration file called .mockery.yaml.
# in project_root/.mockery.yaml
with-expecter: true
packages:
github.com/YangTaeyoung/test-demo-app/service:
config:
all: true
github.com/YangTaeyoung/test-demo-app/repository:
config:
all: true
The with-expecter option allows the use of EXPECT(). It’s possible to write test code without this option, so discussing it in-depth is saved for the test code writing section.
Then enter the following command.
mockery
After this, you will see files created under the mocks directory.
Caution
In collaborative situations, it is recommended to add the generated files to .gitignore. When automatic files generated during a merge conflict, you might end up thinking, “I should be solving conflicts for mocking” repeatedly.
In cases where you have actions for tests in CI/CD tools like Github Actions or Jenkins, you should add a step to install Mockery and generate mock files.
# ...
steps:
# ...
- name: Install Mockery
run: go install github.com/vektra/mockery/v2@v2.53.0
- name: Generate Mocks
run: mockery
- name: Run Tests
run: go test ./...
# ...
Writing Test Code
This time, I used the test addition feature provided by Goland to write the test code. Essentially, Goland generates test code in a Table Driven Test format.
func Test_commentSerivce_CreateComment(t *testing.T) {
type args struct {
ctx context.Context
postingID int
request CreateCommentRequest
}
tests := []struct {
name string
mockPostingRepositry func() repository.PostingRepository
mockCommentRepositry func() repository.CommentRepository
args args
want CreateCommentResponse
wantErr bool
}{
{
name: "posting not found",
mockPostingRepositry: func() repository.PostingRepository {
postingRepository := repository2.NewMockPostingRepository(t)
postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(false, nil)
return postingRepository
},
mockCommentRepositry: func() repository.CommentRepository {
return nil
},
args: args{
ctx: t.Context(),
postingID: 1,
},
want: CreateCommentResponse{
CommentID: 0,
},
wantErr: true,
},
{
name: "success",
mockPostingRepositry: func() repository.PostingRepository {
postingRepository := repository2.NewMockPostingRepository(t)
postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(true, nil)
return postingRepository
},
mockCommentRepositry: func() repository.CommentRepository {
commentRepository := repository2.NewMockCommentRepository(t)
commentRepository.EXPECT().CreateComment(t.Context(), repository.Comment{Content: "content"}).Return(1, nil)
return commentRepository
},
args: args{
ctx: t.Context(),
postingID: 1,
request: CreateCommentRequest{
Content: "content",
},
},
want: CreateCommentResponse{
CommentID: 1,
},
wantErr: false,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
c := &commentSerivce{
postingRepository: tt.mockPostingRepositry(),
commentRepository: tt.mockCommentRepositry(),
}
got, err := c.CreateComment(tt.args.ctx, tt.args.postingID, tt.args.request)
if (err != nil) != tt.wantErr {
t.Errorf("CreateComment() error = %v, wantErr %v", err, tt.wantErr)
return
}
if !reflect.DeepEqual(got, tt.want) {
t.Errorf("CreateComment() got = %v, want %v", got, tt.want)
}
})
}
}
Here we modulated the test cases, and a key point to notice is the mockPostingRepositry and mockCommentRepositry functions.
postingRepository := repository2.NewMockPostingRepository(t)
postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(false, nil)
return postingRepository
Inside the function, we see that NewMockPostingRepository is called, the ExistsByID function is triggered on that object, and the return value is set using Return.
Just looking at this shows that compared to the previous code, not only do you save on making fake objects, but the test code is also much easier to write.
Furthermore, Mockery offers several features, including a way to pass any value with mock.Anything, like this:
commentRepository.EXPECT().CreateComment(t.Context(), mock.Anything).Return(1, nil)
However, it is not recommended for general testing.
The purpose of unit tests is to ensure that the input parameters behave as intended. However, if all parameters are set to mock.Anything, your tests can pass even if the logic for parameter transformation changes. This is because it will pass anything.
Unit testing is convenient for examining small units of functions; in contrast, components like repositories that belong to higher layers can often be mocked with Test DB or similar setups, which I plan to cover in a separate future post.
Return Value Provider Functions
As mentioned, it’s possible to mock without using EXPECT().
// postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(true, nil)
postingRepository.On("ExistsByID", t.Context(), 1).Return(true, nil)
In this way, you can set return values by calling On on the created object. However, since the arguments are literals, there is a higher chance of mistakes due to typos and such, making it more vulnerable to renaming (although modern IDEs can usually handle renaming literals).
Caution
I occasionally see cases where mock.Anything and mock.AnythingOfType are liberally used in all their tests. In fact, such situations cannot legitimately claim to have tested the application thoroughly.
All test codes fundamentally aim to verify whether the application behaves as intended. Unit tests primarily aim to evaluate whether values passed from one layer to another are correctly processed according to the intended design.
For example, in the CreateComment function discussed above, the transformation of CreateCommentRequest to Comment and the return of the commentID as CreateCommentResponse was executed clearly.
While someone could argue that a single field is too obvious to warrant testing, the goal of unit tests is to catch unexpected changes. All unit tests should fail when a change occurs, allowing for easy detection of the origin of any changes, provided the test code is well-constructed.
However, if every parameter is mocked as mock.Anything, even if the logic of parameter transformation changes, the tests will still succeed because they will accept anything.