Четыре простых лайфхака при написании тестов на Go + testify
Хотя язык программирования Go идёт в комплекте со встроенным тестовым фреймворком, мне сложно себе представить написание всего того количества тестов, что я написал, без testify. В этой заметке я расскажу про несколько маленьких неочевидных трюков, которым я научился в процессе.
Различайте assert и require
В testify есть два основных пакета с проверками — assert и require. Набор проверок в них идентичен, но фейл require-проверки означает прерывание выполнения теста, а assert-проверки — нет.
Когда мы пишем тест, мы хотим, чтобы неудачный запуск выдал нам как можно больше информации о текущем (неправильном) поведении программы. Но если у нас есть череда проверок с require, неудачный запуск сообщит нам только о первом несоответствии.
func TestBehavior(t *testing.T) {
...
price, err := priceManager.GetPrice(ctx, productID)
require.NoError(t, err)
require.Equal(t, 300, price.Amount)
require.Equal(t, money.USD, price.Currency)
}
/*
=== RUN TestBehavior
temp_test.go:21:
Error Trace: behavior_test.go:21
Error: Not equal:
expected: 300
actual : 42 // but is it at least bucks?
Test: TestBehavior
--- FAIL: TestBehavior (0.00s)
Expected :300
Actual :42
*/
Поэтому имеет смысл пользоваться require-проверками только если дальнейшее выполнение теста в случае невыполнения условия лишено смысла. Например, когда мы проверяем отсутствие ошибки, или валидируем длину списка, в который полезем дальше по коду теста.
func TestBehavior(t *testing.T) {
...
price, err := priceManager{}.GetPrice(ctx, productID)
require.NoError(t, err)
assert.Equal(t, 300, price.Amount)
assert.Equal(t, money.USD, price.Currency)
}
/*
=== RUN TestBehavior
behavior_test.go:22:
Error Trace: behavior_test.go:22
Error: Not equal:
expected: 300
actual : 42
Test: TestBehavior
behavior_test.go:23:
Error Trace: behavior_test.go:23
Error: Not equal:
expected: USD
actual : RUB
Test: TestBehavior
--- FAIL: TestBehavior (0.00s)
*/
Также стоит быть осторожнее при использовании горутин в тестах. require-проверки производятся через runtime.goexit(), так что они сработают ожидаемым образом только в основной горутине.
Используйте подходящие проверки вместо универсальных
Очевидно, для реализации практически любого мыслимого теста (кроме паникующего) достаточно одной функции assert.True(). Тем не менее, в testify есть уйма проверок для разных случаев жизни. Использование более подходящей проверки делает сообщения об ошибках более читаемыми и экономит код.
❌ require.Nil(t, err)
✅ require.NoError(t, err)
❌ assert.Equal(t, 300.0, float64(price.Amount))
✅ assert.EqualValues(t, 300.0, price.Amount)
❌ assert.Equal(t, 0, len(result.Errors))
✅ assert.Empty(t, result.Errors)
❌ require.Equal(t, len(expected), len(result)
sort.Slice(expected, ...)
sort.Slice(result, ...)
for i := range result {
assert.Equal(t, expected[i], result[i])
}
✅ assert.ElementsMatch(t, expected, result)
Аналогично, тест по умолчанию считается упавшим в случае паники, но использование assert.NotPanics() помогает будущему читателю теста понять, что вы проверяете именно её отсутствие.
Структурируйте тесты с помощью Suite и t.Run ()
Этот совет может звучать совсем уж очевидным, но плохо структурированные тесты — проблема, которая встречаетсявстречающаяся повсеместно.
Suite собирает тесты, объединённые общими компонентами и тестовыми данными.
Методы сюиты проверяют разные, независимые друг от друга сценарии использования этих компонент и сущностей. Они могут запускаться в произвольном порядке.
Секции t.Run () разделяют сценарии на последовательные логические части.
При этом возможностью двухуровнево структурировать тесты внутри сюиты легко злоупотребить — этого тоже следует избегать. Однажды я наткнулся на сюиту в 2 000 строк кода — и оказалось, что это маленький тест, который я написал несколько лет назад и назвал слишком общими словами, спровоцировав коллег одного за другим добавлять туда новые тесты для совершенно несвязанных фичей. Зато каждый тест был в отдельном методе.
Прячьте вспомогательные методы за //go: build
Иногда в тестах бывает необходимо вызвать какой-то метод у объекта, который в обычном продакшне не нужен (или даже опасен). Например, если у нас есть компонент с кэширующим слоем и мы хотим после изменения каких-то тестовых данных этот кэш сбросить.
В таком случае удобно положить реализацию этого метода и тестовый интерфейс в отдельный файл с именем *_test.go. Так мы выставляем наружу нужные для тестирования методы, но не засоряем публичный интерфейс пакета.
package mypackage
type TestManager interface {
Manager
ClearCache(ctx context.Context) error
}
// Поскольку мы в том же пакете, мы можем обращаться
// к приватным структурам и даже добавлять новые методы.
func (m *manager) ClearCache(ctx context.Context) error {
return m.myStuffCache.Clear(ctx)
}
Однако, в таком случае наш тестовый тип и метод будут доступны только в тестах в этой же папке: в пакетах mypackage и mypackage_test. Это довольно серьёзное ограничение. (Также для таких ситуаций предусмотрен довольно хитрый механизм сборки, способный значительно замедлить покоммитные тесты.)
Гораздо универсальнее и удобнее положить их в обычный .go-файл и выключить его компиляцию клаузой //go:build testmode.
//go:build testmode
package mypackage
type TestManager interface {
Manager
ClearCache(ctx context.Context) error
}
func (m *manager) ClearCache(ctx context.Context) error {
return m.myStuffCache.Clear(ctx)
}
При этом нужно будет начать прокидывать -tags testmode при прогоне тестов и сделать отдельную джобу, проверяющую сборку бинарей без этого тега (если у вас в принципе есть CI/CD).
Также в файлы с //go:build testmode можно складывать тестовые утилиты, свои кастомные сюиты со вспомогательными методами и так далее.
А какие best practices написания тестов на Go используете вы? Поделитесь в комментариях!
