Как писать unit-тесты в Go? Какие инструменты и подходы используются?

Ага, смотри, вот тебе про тесты в Go, но без этой занудной академической хуйни. Сядь, слушай.

Так, значит, ты пишешь код на Go. И ты, конечно, не мудак, который потом руками всё проверяет. Ты пишешь тесты. В Go с этим всё просто, но есть свои приколы, которые надо знать, чтобы не обосраться.

Чем тут можно пользоваться, как инструментами

1. testing — родной пакет. Это как родная хата, всё есть, но без особых удобств. Пишешь файлы с названием что-то_test.go, кричишь go test, и он всё прогоняет. Без этого нихуя.
2. testify/assert и testify/require — твои лучшие друзья. Это уже не родная хата, а евроремонт. Вместо того чтобы писать if got != want { t.Errorf(...) }, ты просто орёшь assert.Equal(t, ожидаемое, полученное). Разница в том, что assert после ошибки продолжает тест, а require — сразу в сраку, прерывает всё. Выбирай по характеру.
3. Моки (testify/mock или gomock). Это когда твой код общается с какой-то внешней хуйнёй — базой данных, другим сервисом. Чтобы не зависеть от того, жива ли эта хуйня, ты создаёшь её муляж — мок. И говоришь этому муляжу: «Слушай, когда к тебе обратятся, сделай вид, что ты база данных, и верни вот это». Идеально для изоляции.

Как не выстрелить себе в ногу: главные подходы

1. Табличные тесты (Table-Driven Tests). Это святое, блядь. Не пиши ты десять функций TestSum_WithPositive, TestSum_WithNegative. Ты чё, совсем? Создаёшь один срез структур, где каждая строка — это отдельный тестовый случай: что на вход, что ожидаешь на выходе, и название, чтобы потом в логах не ебаться. Элегантно и сука эффективно.
2. Мокирование. Твой код не должен падать, потому что упала база. Поэтому все зависимости выносишь в интерфейсы. А в тесте вместо реальной базы подсовываешь мок, который этот интерфейс реализует и делает только то, что тебе нужно для теста. Чистая изоляция, как в боксе.
3. Гонки данных (Race Condition). А вот это, ёпта, самая хитрая жопа в многопоточности. Два потока лезут в одну переменную, и кто первый — хрен знает. Go тебе в помощь: запускаешь тесты с флагом -race, и он тебе подсветит, где у тебя эти опасные места. Обязательно делай.
4. Покрытие кода (Code Coverage). Чтобы не было стыдно перед коллегами. go test -cover покажет процент. А если хочешь красивую картинку, где именно не покрыто, то go test -coverprofile=coverage.out && go tool cover -html=coverage.out — откроет в браузере, и ты увидишь, где ты сэкономил на тестах, пидарас.

Пример, чтобы было понятно, как это выглядит вживую

Допустим, у тебя есть функция сложения, проще некуда:

// calculator.go
package main

func Sum(a, b int) int {
    return a + b
}

Вот как для неё писать тест по-взрослому, с таблицей:

// calculator_test.go
package main

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestSum(t *testing.T) {
    // Вот она, мать её, таблица. Всё красиво и в одном месте.
    testCases := []struct {
        name string // Как обозвать случай, чтобы в логах не "TestSum/0" было
        a    int    // Первое слагаемое
        b    int    // Второе слагаемое
        want int    // Что, блядь, должно получиться
    }{
        {"Два плюса", 2, 3, 5},
        {"Плюс и минус", 5, -3, 2},
        {"Два минуса", -1, -1, -2},
        {"С нулём", 10, 0, 10},
    }

    // Пробегаемся по всей таблице
    for _, tc := range testCases {
        t.Run(tc.name, func(t *testing.T) { // Запускаем подтест с вменяемым именем
            got := Sum(tc.a, tc.b) // Вызываем тестируемую функцию
            assert.Equal(t, tc.want, got, "А сумма-то не сошлась, ёпта!") // Проверяем
        })
    }
}

Вот и вся магия. Ничего сложного, но делать надо. Иначе потом будешь как тот Герасим — молча страдать, когда продакшн упадёт в три часа ночи.