프로그래밍을 하다 보면 어떤 코드이던 간에 제대로 동작하는지 확인해야 할 때가 있다.
API 서버라면, 직접 호출로 특정 프로그램이라면 버튼을 누른다던지 등으로 직접 테스트 해 볼 수도 있다.
다만 레이어가 깊어질 수록, 관계성이 많은 데이터가 있으면 있을 수록 테스트하기 어려울 수 있다.
예를 들어 다음과 같은 관계를 가진 데이터가 있다고 가정해보자
graph TD
comment --> post
post --> user
user --> comment
그리고 인터페이스는 다음과 같다.
type CommentService interface {
CreateComment (ctx context.Context, postingID int, request CreateCommentRequest) (CreateCommentResponse, error)
}
이런 경우 코멘트가 잘 생성되었는지 다음과 같은 과정을 거쳐야 한다.
- 유저를 생성한다.
- 포스트를 생성한다.
- 코멘트를 생성한다.
- DB에 저장된 데이터를 확인한다.
하면 할 수 있는 작업이지만, 이런 작업을 매번 모든 함수를 짤 때마다 해야한다면, 관계가 복잡하면 할 수록 알아야 할 컨텍스트 량이 늘어나기에 점점 테스트하기 어려워 질 수 있을 것이다.
이럴 때 바로 유닛테스트를 활용해볼 수 있다.
유닛 테스트
이름에서 유추할 수 있듯이, 유닛 테스트는 코드의 단위를 테스트하는 것이다. 특정 단위의 코드가 의도한 대로 동작하는지 확인하는 것이다.
정의로는 코드의 가장 작은 기능적 단위를 테스트 하는 프로세스이다
여기서 기능적 단위란 여러 가지가 될 수 있지만, 일반적이고 보편적으로는 함수 단위로 테스트를 진행한다.
위에서 살펴본 CreateComment의 내부 플로우는 다음과 같다고 가정해보자
sequenceDiagram
CommentHandler ->> CommentService: postingId, request
CommentService ->> PostingRepository: ExistsByID
PostingRepository -->> CommentService: true
CommentService ->> CommentRepository: CreateComment
CommentRepository -->> CommentService: commentID
CommentService -->> CommentHandler: commentID
코드로 표현하면 이런 모양일 것이다.
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
}
유닛 테스트 대상 선정하기
여기서 이 함수에서 테스트 해야할 코드 대상은 무엇일까?
exists, err := c.postingRepository.ExistsByID(ctx, postingID)
if err != nil {
return CreateCommentResponse{}, err
}
if !exists {
return CreateCommentResponse{}, errors.New("posting not found")
}
먼저 위 코드를 보자. ExistsByID의 내부 함수 코드를 우리가 테스트할 필요가 있을까?
그럴 필요는 없다. 왜냐하면 우리가 테스트하고자 하는 것은 CreateComment 함수이지 ExistsByID가 아니기 때문이다.
반환하는 에러 역시 이미 ExistsByID 함수에서 테스트 되었다고 가정하고 별도의 테스트 코드를 위해 분기하진 않는다.
해도 상관은 없지만, 필자의 경우에는 단순히 커버리지만을 위한 코드로 보여 별도 테스트 케이스로 분리하진 않는 편이다.
여기서 그럼 ExistsByID와 관련된건 아무것도 테스트 하지 않는 것인지 질문할 수 있는데 그런 것은 아니다.
ExistsByID에 요청으로 들어온 postingID가 잘 들어오는지 입력에 대한 검증이 추가적으로 필요하다.
또한 응답으로 나오는 exists값을 이용해 별도로 분기하고 있기에 해당 코드에 대한 검증도 필요하다.
근데 ExistsByID 호출을 하면 결국 테스트 하게 되는 것이 아닌가?
맞다. ExistsByID를 호출하면 결국 ExistsByID에 대한 테스트도 진행하게 된다고 생각할 수 있다.
실제 객체를 사용하면 결국 ExistsByID를 호출하여 DB까지 접근하게 되겠지만, 여러 언어에 있는 테스트 프레임워크에는 항상 Mock이라는 기능을 제공한다.
Mock
Mock은 테스트 중에 실제 객체를 대신하여 사용할 수 있는 가짜 객체이다.
위 그림과 같이 실제 환경에서는 실제 DB와 연결된 commentRepository 객체를, 테스트 환경에서는 fakeCommentRepository 객체를 사용하여 테스트를 진행하는 개념이다.
인터페이스를 이용한 다형성 개념을 활용한다고 보면 된다.
PostgresDB로 구현한 객체를 다른 Redis로 구현한 객체로 갈아끼울 수도 있듯이, 테스트 환경에서 구현된 객체로 갈아끼울 수도 있는 것이다.
Golang mock, Mockery 등의 다양한 라이브러리가 있지만, 우선 없다고 했을 때, 어떻게 직접 구현하여 해당 코드를 테스트 할 수 있을지 알아보자
테스트 코드 작성하기
위에서 유닛 테스트 코드의 개념을 알아보았다. 이제 실전이다.
아까 예시로 들었던 CreateComment 함수를 테스트하는 코드를 작성해보자.
먼저 테스트 파일에서 모의 객체를 작성한다.
// 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)
}
Func를 굳이 구조체 필드에 추가한 이유는 테스트 코드에서 해당 함수를 호출할 때, 테스트 코드에서 원하는 값을 검사하고, 반환하도록 하기 위함이다.
그리고 아래 부분의 테스트 코드를 작성해보자
먼저 posting이 없을 때의 테스트 코드이다.
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")
}
})
}
테스트 코드 내에서 fakePostingRepository를 초기화 하고 argument인 postingID가 의도한 값, 즉 1로 들어왔는지 를 테스트 하고 그렇지 않다면 테스트가 아예 종료되도록 했다.
다시 비즈니스 로직을 보면 나머지 코드는 err != nil 분기를 제외하면 모두 이렇다할 분기는 존재하지 않는다.
이제 바로 정상 케이스를 작성하면 된다.
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), 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)
})
}
먼저 값을 체크하는 라이브러리를 testify로 바꿨는데, Java의 AssertJ처럼.Golang 내부에서는 거의 표준처럼 사용되고 있다. Reflection을 이용한 비교가 가능하기에, 포인터 등을 비교할 때에도 문제 없이 사용할 수 있다.
이후에 호출되는 CreateCommentFunc도 추가했는데, 앞선 설명과 같이 파라미터를 검사하고 Output으로 생성된 commentID를 모사하여 1로 응답한다
이렇게 테스트 코드를 작성하면, 해당 함수의 비즈니스 로직에 대한 테스트 코드를 작성할 수 있다.
생각보다 이렇게 작성하는 것도 어렵진 않지만, 문제가 있는 부분도 있다.
직접 작성을 하다보면, 이것저것 Repository를 사용한다면 파일마다 이런 테스트 코드를 작성해야 하기에 조금 불편할 수 있을 것이다.
이때 앞서 언급했던 두 라이브러리, Golang mock, Mockery를 사용하여 좀 더 편하게, 그리고 부가기능이 더 다양한 Mocking 된 구현체를 쉽게 찍어낼 수 있다.
여기서 Golang mock은 Go의 공식 패키지이긴 하지만 2023년에 Archived 되어 더 이상 관리되지 않기 때문에 그리 추천하진 않는다. 좀 더 활발하게 관리되는 Mockery를 사용하는 것을 추천한다. Star도 꽤 많고, 기능도 유용하다
Mockery
Mockery를 알아보기 전 폴더 구조를 정리해야 한다. Mockery는 다 좋은데 설정이 복잡한 편이고, 추가할 때마다 패키지 설정이 필요한 편이라 좀 더 유의해야 한다.
코드 자체는 크게 변함이 없지만, 독자가 해당 코드만으로도 정확한 테스트 할 수 있도록 위해 해당 섹션을 남겨두는 것이기에, 이미 익숙하다면 해당 섹션은 패스해도 좋다
// 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
}
이후 다음 커맨드로 Mockery 라이브러리를 설치한다. 버전은 그때 그때 출시에 따라 달라지므로 릴리즈를 참고하자
go install github.com/vektra/mockery/v2@v2.53.0
그리고 .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
with-expecter인자는 EXPECT()를 사용할 수 있게 해주는 옵션이다. 이 옵션을 사용하면, 테스트 코드를 작성할 때, EXPECT()를 사용할 수 있다.
없이도 테스트 코드를 작성할 수 있으니 해당 옵션에 대한 부분은 아래 테스트 코드 작성 단계에서 보다 자세히 살펴보자
그리고 다음 명령어를 입력한다.
mockery
그럼 mocks에 다음과 같이 파일이 생성된 것을 볼 수 있다.
주의점
협업 상황에서 해당 생성된 파일은 .gitignore에 추가할 것을 권장한다. merge 할 때 자동 생성 된 파일끼리 충돌이 있으면 mock을 위해서 이 충돌을 해결하고 있어야 하나 하는 자괴감이 들 때가 종종 생기기 때문이다.
이 경우 Github Actions이나, Jenkins와 같은 CI/CD 툴 등에 테스트를 위한 액션을 추가해두었다면, mockery설치하고, Mock파일을 생성하는 스탭을 추가해야 한다.
# ...
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 ./...
# ...
테스트 코드 작성
이번엔 Goland에서 제공하는 테스트 추가 기능을 이용해 테스트 코드를 작성해보았다. 기본적으로 Goland는 Table Driven Test으로 테스트 코드를 생성한다.
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)
}
})
}
}
테스크 케이스를 좀 조율했고, 주의해서 봐야 할 점은 mockPostingRepositry와 mockCommentRepositry 함수이다.
postingRepository := repository2.NewMockPostingRepository(t)
postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(true, nil)
return postingRepository
내부 함수를 보면, NewMockPostingRepository를 호출하고, 해당 객체에 ExistsByID 함수를 호출하고, Return을 통해 반환값을 설정한다.
함수명의 인자에는 실제 들어가는 인자들을, Return에는 인자값 매칭 성공시 반환할 반환값을 넣어주면 된다.
이것만 봐도, 아까 작성했던 코드량 대비 fake 객체를 만들어도 되지 않아도 된다는 부분과, 테스트 코드 작성이 훨씬 간편해진 것을 알 수 있다.
또 여러가지 기믹들도 제공하는데 다음처럼 아무거나 들어와도 통과시키도록 mock.Anything을 사용해볼 수도 있다
commentRepository.EXPECT().CreateComment(t.Context(), mock.Anything).Return(1, nil)
물론 일반적인 테스트에서는 절대 권장하지 않는다.
유닛 테스트에서는 인자값이 제대로 의도에 맞는지 테스트하는 것이 중요하기 때문이다. 다만, 랜덤함수나 uuid.New(), time.Now()같이 테스트하기 어려운 함수들을 테스트할 때 제한적으로 사용하면 꽤나 편리하게 사용할 수 있다.
유닛 테스트는 이처럼 작은 단위의 함수를 테스트하기 용이하다, 위치상 상위 레이어에 속하는 Repository와 같은 경우는 실제 DB를 모사하기 위해 Test DB등을 적용해볼 수 있는데, 해당 부분은 현재 포스팅에서 작성하면 매우 글이 길어질 것 같아 추후 포스팅에서 후술하도록 하겠다.
Return Value Provider Functions
앞서서 EXPECT()를 사용하지 않고서도 mocking을 할 수 있다.
// postingRepository.EXPECT().ExistsByID(t.Context(), 1).Return(true, nil)
postingRepository.On("ExistsByID", t.Context(), 1).Return(true, nil)
위처럼 생성한 객체에 On 함수를 사용하면, EXPECT()와 함꼐 해당 함수를 호출하면서 반환값을 설정할 수 있다. 다만 인자가 리터럴이기에 사용자가 오타 등으로 실수할 수 있는 확률이 좀 더 크며, 리네이밍 등에 취약하다 (다만 요즘 IDE들은 리터럴 리네이밍도 다 해주긴 하는 것 같다.)
주의점
가끔 mock.Anything, mock.AnythingOfType 등을 이용해서 모든 테스트에 덕지덕지 발라놓은 것이 보인다. 사실 해당 경우는 어플리케이션을 제대로 테스트했다고 절대 할 수 없다.
모든 테스트 코드는 기본적으로 사용자가 의도한 대로 동작하는지를 테스트 하는 것이다.
유닛 테스트는 그 중 코드 레벨에서, 사용자가 전달한 것이 제대로 가공되어 상위레이어로, 하위레이어로 전달한 의도에 맞게 가공된 값을 서로 주고 받는지 검증 하는 것에 그 목적이 있다.
예를 들어 위에서 다루었던 CreateComment 함수에서는 CreateCommentRequest가 Comment로, 반환값이었던 commentID가 CreateCommentResponse로 변환되어 반환되었다.
혹자는 필드가 하나밖에 없고 그건 너무 뻔한데 굳이 테스트 할 필요 있나 라고 반문할 수 있다. 또 값을 바꾸면 테스트가 깨진다고 하면서 말이다.
기본적으로 유닛테스트는 값을 바뀌면 깨져야 깨닫지 못했던 변경사항을 알아챌 수 있고, 그게 특정 함수로 인한 변경점이라면 유닛테스트 코드가 잘 짜져있다는 가정하에서는 모든 변경점을 테스트가 실패하는 것으로 알아챌 수 있다.
다만 모든 파라미터가 mock.Anything으로 되어있다면, 파라미터 변환 로직이 변경되었다 하더라도 테스트 코드는 통과할 것이다. 아무거나 통과시키기로 했기 때문이다.