Табличные тесты в Go с использованием Gomock

Чтобы эффективнее тестировать работу программы, можно использовать табличные юнит-тесты. В этой статье пошагово рассказываем, как писать такие тесты с помощью фреймворка Gomock.

Этот текст написал Golang-разработчик Арек Ностер. С разрешения автора мы перевели статью.

Чтобы погрузиться в Go-тестирование, можно почитать ещё эти материалы:

• Что представляет собой юнит-тестирование (eng). 

• Тестовые двойники в Go: имитации, моки и заглушки (eng).

• Табличные тесты в Go (eng).

Создаём проект

Давайте представим, что мы решили создать приложение для вечеринок. Это хороший пример использования Gomock в табличных тестах. Приложение будет собирать имена людей, которые зарегистрировались на встречу, и писать каждому приветственное сообщение в консоли.

Примечание: весь исходный код c примером доступен на GitHub. В тексте статьи будем последовательно показывать нужные участки кода.

Определяем домен

В первую очередь нужно определить сущность гостя и методы поведения на уровне домена:

type Visitor struct { Name    string Surname string }  func (v Visitor) String() string { return fmt.Sprintf("%s %s", v.Name, v.Surname) }

package party  type Greeter interface { Hello(name string) string }

package party  type VisitorGroup string  const ( NiceVisitor    VisitorGroup = "nice" NotNiceVisitor VisitorGroup = "not-nice" )  type VisitorLister interface { ListVisitors(who VisitorGroup) ([]Visitor, error) }

Не будем использовать конкретную имплементацию Greeter и Visitor Lister — в юнит-тестировании нужно избегать зависимостей.

Далее создадим сервис с методом GreetVisitors, который будем тестировать:

package app  import ( "fmt" "github.com/areknoster/table-driven-tests-gomock/pkg/party" )  type PartyService struct { visitorLister party.VisitorLister greeter       party.Greeter }  func NewPartyService(namesService party.VisitorLister, greeter party.Greeter) *PartyService { return &PartyService{ visitorLister: namesService, greeter:       greeter, } }  func (s *PartyService) GreetVisitors(justNice bool) error { visitors, err := s.visitorLister.ListVisitors(party.NiceVisitor) if err != nil { return fmt.Errorf("could get nice people names: %w", err) } if !justNice { notNice, err := s.visitorLister.ListVisitors(party.NotNiceVisitor) if err != nil { return fmt.Errorf("could not get not-nice people's names' ") } visitors = append(visitors, notNice...) } for _, visitor := range visitors { fmt.Println(s.greeter.Hello(visitor.String())) } return nil }

Теперь сервис готов к тестированию.

Пишем тесты при помощи Gomock

Вы можете заметить, что метод GreetVisitors довольно сложно тестировать, потому что:

• он полагается на свои зависимости;

• мы не можем проверить результат выполнения функции;

• выход из функции осуществляется в нескольких местах.

В процессе юнит-тестирования важно не завязывать реализацию на конкретные зависимости, иначе код будет сложно проверить.

В Golang есть много способов имитировать поведение зависимости. Самый простой из них — явно прописать возвращаемые результаты. Чтобы упростить этот процесс, можно воспользоваться фреймворком. Мы выбрали Gomock, потому что в нём можно точно сопоставить аргументы вызовов функций и результаты их выполнения. А так же он активно поддерживается сообществом.

Генерируем код через Mockgen

Mockgen — это инструмент в Go, который генерирует структуры. Mockgen устанавливается так же, как и другие инструменты Golang. 

GO111MODULE=on go get github.com/golang/mock/mockgen@v1.4.3

или

go get github.com/golang/mock/mockgen

Выбираем режим 

У Mockgen есть два режима. Их определения мы взяли из репозитория.

• Режим reflection: генерирует мок-интерфейсы через анализ интерфейсов с помощью reflection.

• Режим исходника: генерирует мок-интерфейсы из файла-исходника. Для этого нужно применить флаг «-source».

Основные различия этих режимов:

• Режим исходника позволяет создавать неэкспортируемые интерфейсы, в то время как сам Mockgen в этом режиме статично парсит код.

• Режим reflection можно использовать с аннотациями go:generate. 

• Режим reflection даёт больше контроля над тем, что, где и когда генерируется.

Мы решили использовать режим исходника. Пришлось пожертвовать точностью, но мы это сделали ради хорошей и чёткой структуры.

Вот Makefile, который может быть полезным:

MOCKS_DESTINATION=mocks .PHONY: mocks # put the files with interfaces you'd like to mock in prerequisites # wildcards are allowed mocks: pkg/party/greeter.go pkg/party/visitor-lister.go @echo "Generating mocks..." @rm -rf $(MOCKS_DESTINATION) @for file in $^; do mockgen -source=$$file -destination=$(MOCKS_DESTINATION)/$$file; done 

После того, как примените Makefile, вы получите папку с моком — её содержание полностью повторяет структуру файлов проекта.

Используем мок-объекты

Теперь перейдём к тестированию. Для начала возьмём простой тест с одним кейсом. Так выглядит тест-кейс в нетабличном подходе:

func TestPartyService_GreetVisitors_NotNiceReturnsError(t *testing.T) { // инициализируем контроллер gomock ctrl := gomock.NewController(t) // если не все ожидаемые вызовы будут исполнены к завершению функции, тест будет провален defer ctrl.Finish() // структура init, которая реализует интерфейс party.NamesLister mockedVisitorLister := mock_party.NewMockVisitorLister(ctrl) // mockedVisitorLister, ожидаем, что mockedVisitorLister будет вызван один раз с аргументом party.NiceVisitor и вернёт []string{“Peter”, "TheSmart"}, nil mockedVisitorLister.EXPECT().ListVisitors(party.NiceVisitor).Return([]party.Visitor{{"Peter", "TheSmart"}}, nil) // mockedVisitorLister, ожидаем, что метод mockedVisitorLister.ListVisitors будет вызван один раз с аргументом party.NotNiceVisitor и вернёт nil и ошибку mockedVisitorLister.EXPECT().ListVisitors(party.NotNiceVisitor).Return(nil, fmt.Errorf("dummyErr")) // mockedVisitorLister реализует интерфейс party.VisitorLister, чтобы его можно было привязать к PartyService sp := &PartyService{ visitorLister: mockedVisitorLister, } gotErr := sp.GreetVisitors(false) if gotErr == nil { t.Errorf("did not get an error") } }

Если вам нужны более продвинутые настройки моков, сверьтесь с документацией Gomock.

Пишем табличные тесты

Теперь посмотрим, как использовать Gomock в табличных тестах. Этот шаблон был сгенерирован инструментом gotests:

func TestPartyService_GreetVisitors(t *testing.T) { type fields struct { visitorLister party.VisitorLister greeter       party.Greeter } type args struct { justNice bool } tests := []struct { name    string fields  fields args    args wantErr bool }{ // TODO: Добавляем тест-кейсы } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { s := &PartyService{ visitorLister: tt.fields.visitorLister, greeter:       tt.fields.greeter, } if err := s.GreetVisitors(tt.args.justNice); (err != nil) != tt.wantErr { t.Errorf("GreetVisitors() error = %v, wantErr %v", err, tt.wantErr) } }) } }

Дизайн Gomock не даёт инициализировать и устанавливать ожидаемые вызовы функций в одном выражении. Именно поэтому нужно делать это до тест-кейсов.

Мы хотим, чтобы наши тесты стали идемпотентными. Для этого каждый из них будет требовать отдельной инициализации. Если на руках будет несколько тестов, можно запутаться. Поэтому мы изменили структуру кода:

func TestPartyService_GreetVisitors(t *testing.T) { // встраиваем мок-объекты вместо интерфейса, чтобы установить ожидания type fields struct { visitorLister *mock_party.MockVisitorLister greeter       *mock_party.MockGreeter } type args struct { justNice bool } tests := []struct { name    string // «prepare» позволяет инициализировать наши моки в рамках конкретного теста prepare func(f *fields) args    args wantErr bool }{ // TODO: Добавляем тест-кейсы } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { ctrl := gomock.NewController(t) defer ctrl.Finish() f := fields{ visitorLister: mock_party.NewMockVisitorLister(ctrl), greeter:       mock_party.NewMockGreeter(ctrl), } if tt.prepare != nil { tt.prepare(&f) }  s := &PartyService{ visitorLister: f.visitorLister, greeter:       f.greeter, } if err := s.GreetVisitors(tt.args.justNice); (err != nil) != tt.wantErr { t.Errorf("GreetVisitors() error = %v, wantErr %v", err, tt.wantErr) } }) } }

Контроллер Gomock инициализируется внутри t.Run, а expectations устанавливаются для каждого отдельного кейса в prepare function.

Теперь тесты полностью идемпотентны: благодаря этому можно определять, какие вызовы будут выполняться на зависимостях. Если что-то пойдёт не так, вы получите сообщение с указанием конкретных вызовов, которые не были исполнены.

tests := []struct { name    string prepare func(f *fields) args    args wantErr bool }{ { name: "visitorLister.ListVisitors(party.NiceVisitor) returns error, error expected", prepare: func(f *fields) { f.visitorLister.EXPECT().ListVisitors(party.NiceVisitor).Return(nil, fmt.Errorf("dummyErr")) }, args:    args{justNice: true}, wantErr: true, }, { name: "visitorLister.ListVisitors(party.NotNiceVisitor) returns error, error expected", prepare: func(f *fields) { // если указанные вызовы не станут выполняться в ожидаемом порядке, тест будет провален gomock.InOrder( f.visitorLister.EXPECT().ListVisitors(party.NiceVisitor).Return([]string{"Peter"}, nil), f.visitorLister.EXPECT().ListVisitors(party.NotNiceVisitor).Return(nil, fmt.Errorf("dummyErr")), ) }, args:    args{justNice: false}, wantErr: true, }, { name: " name of nice person, 1 name of not-nice person. greeter should be called with a nice person first, then with not-nice person as an argument", prepare: func(f *fields) { nice := []string{"Peter"} notNice := []string{"Buka"} gomock.InOrder( f.visitorLister.EXPECT().ListVisitors(party.NiceVisitor).Return(nice, nil), f.visitorLister.EXPECT().ListVisitors(party.NotNiceVisitor).Return(notNice, nil), f.greeter.EXPECT().Hello(nice[0]), f.greeter.EXPECT().Hello(notNice[0]), ) }, args:    args{justNice: false}, wantErr: false, }, }

Так выглядят готовые тест-кейсы в табличном стиле.