👨‍💻 Покрытие кода тестами в Go

Команда DoltHub пишет Dolt на Go уже много лет. Тесты у них есть в огромном количестве, но покрытие кода они никогда не измеряли. Недавно один из инженеров вспомнил, что Go добавил поддержку инструментирования покрытия в обычных бинарниках ещё в версии 1.20, не только в go test. Решили проверить, что из этого выйдет.

Хорошая часть их покрытия приходит на интеграционные тесты, которые запускают бинарник напрямую, а не через go test. В частности, у них тысячи BATS-тестов для CLI, и большая часть кодовой базы проверяется только ими.

Для юнит-тестов достаточно добавить несколько флагов к go test:

go test -cover -coverpkg="$COV_PKGS" ./... -args -test.gocoverdir=/tmp/coverdata/unit

Флаг -cover включает сбор данных. -coverpkg задаёт список пакетов для инструментирования. Чтобы не перечислять их вручную, используют go list:

go list -f '{{if not .Standard}}{{.ImportPath}}{{end}}' -deps . | \
    grep dolthub | paste -sd"," - > "pkgs.txt"

export COV_PKGS=$(cat pkgs.txt)

Для интеграционных тестов собирают инструментированный бинарник:

go build -cover -coverpkg="$COV_PKGS" ./cmd/dolt/.
export GOCOVERDIR=/tmp/coverdata/integration

Теперь любой запуск этого бинарника пишет данные о покрытии в указанную директорию.

После всех прогонов данные сводятся в один файл:

go tool covdata textfmt -i /tmp/coverdata/unit,/tmp/coverdata/integration -o cov.out
go tool cover -html=cov.out

Получается HTML-файл с построчным покрытием. Проблема в том, что стандартный интерфейс предлагает выбрать нужный файл из выпадающего списка всех 1910 файлов проекта что неудобно.

Команда DoltHub написала свой конвертер поверх стандартного вывода: он разбивает результат по отдельным файлам и добавляет индексную страницу с сортировкой по уровню покрытия.

Что получилось в итоге

Итоговый отчёт охватывал 1910 файлов со средним покрытием 49%. Ниже, чем типичные 70% в Java-проектах. Но результат объясним: в числе проанализированных файлов оказались форкнутые зависимости вроде Vitess, мёртвый код и автогенерированные фичи без тестов.

Когда результаты показали коллегам, реакция была спокойной. Никто не рвался писать новые тесты, чтобы поднять цифры. Всех больше интересовало, какой AI-инструмент помог сгенерировать отчёт.

Три причины, почему покрытие не стало приоритетом:

1. Кодовая база большая: больше полумиллиона строк кода. Понять, с чего начать после восьми лет без покрытия, непросто.

2. Go-код даёт много шума из-за обработки ошибок. Каждый блок if err != nil порождает непокрытую ветку, и требовать её покрытия нереалистично.

3. У команды уже есть наборы тестов, которым они доверяют.

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

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

⭐️ Task без установки

Если вы пишете на Go и используете Task как таск-раннер, то знаете боль: нужно попросить коллег установить его. У каждого свой пакетный менеджер, своя ОС, свои предпочтения. Часть поставит через Homebrew, часть через apt, часть скачает бинарник вручную. А потом окажется, что версии у всех разные.

Начиная с Go 1.24 это можно решить через механизм go tool.

Что делает go tool

Go умеет компилировать и запускать внешние инструменты, объявленные как зависимости проекта. Версия фиксируется в go.mod, и Go кеширует скомпилированный бинарник, так что повторные вызовы работают быстро.

Как подключить Task

Добавляем Task как tool-зависимость проекта:

go get -tool github.com/go-task/task/v3/cmd/task@latest

В go.mod появится строка:

tool github.com/go-task/task/v3/cmd/task

Вместо просто task везде пишем go tool task:

go tool task build
go tool task test
go tool task lint

Зачем это нужно

• Версия Task теперь зафиксирована в go.mod и go.sum, как любая другая зависимость. Dependabot или Renovate будут обновлять её автоматически.

• CI больше не требует отдельного шага установки Task. Достаточно, чтобы в образе был Go, и go tool task сделает остальное самостоятельно.

• Новые разработчики в команде не тратят время на выяснение, как и откуда ставить таск-раннер. Они просто клонируют репозиторий и работают.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

📶 WiFi на ESP32 через TinyGo

espradio это пакет для TinyGo, который добавляет поддержку беспроводной связи на ESP32-C3 и ESP32-S3. Работает режим WiFi-клиента, точки доступа и сканирование сетей

Под капотом два слоя.

Нижний это бинарные блобы от Espressif, которые вызываются напрямую через CGo. Они отвечают за низкоуровневую работу с радиомодулем.

Верхний слой — чистый Go: пакет lneto реализует сетевой стек второго уровня.

Помимо простого HTTP-сервера в репозитории есть примеры для MQTT, , точки доступа с DHCP-сервером, сканирования WiFi-сетей и низкоуровневой работы через lneto без net/http.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

😎 Топ-вакансий для Go-разработчиков за неделю

Middle GoLang Developer — удалёнка по США

Senior Golang Developer — офис в Москве

Golang developer — гибрид в МСК

➡️ Еще больше топовых вакансий — в нашем канале Go jobs

🐸 Библиотека Go-разработчика

#GoWork

🗓 В следующий вторник (28.04) в 19:00 встречаемся в онлайне.

Тема:

Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены

В кружке Кирилл Кухарев рассказал, какие именно подходы будем разбирать.

👉 Занять место на вебинаре

⚙️ slicessort: заменяем sort.Slice на slices.Sort

В Go есть анализатор slicessort из пакета golang.org/x/tools/go/analysis. Он находит в коде паттерны сортировки через sort.Slice с простой функцией сравнения и предлагает заменить их на slices.Sort.

Что он решает

Раньше, чтобы отсортировать срез базовых типов по возрастанию, писали так:

sort.Slice(s, func(i, j int) bool { return s[i] < s[j] })

Это работает, но многословно. Начиная с Go 1.21 есть slices.Sort, которая делает то же самое без лишнего кода:

slices.Sort(s)

Анализатор проверяет вызовы sort.Slice и ищет те, где функция-компаратор просто сравнивает элементы через <. Если срез содержит упорядоченный базовый тип (int, string, float64 и другие), анализатор помечает такой вызов и предлагает замену.

Запустить можно через go vet или любой линтер, поддерживающий analysis.Analyzer:

go vet -vettool=$(which slicessort) ./...

Или через golangci-lint, если анализатор подключён в конфиге.

slicessort не делает ничего сложного. Он просто убирает бойлерплейт там, где стандартная библиотека уже давно предлагает лучше. Если проект на Go 1.21+, стоит добавить его в пайплайн.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

🛠 make как точка входа в Go-проект

Когда работаете над Go-проектом в команде, быстро появляется проблема: каждый запускает сборку и тесты по-своему. Один пишет go build -o app, другой забыл флаги линтера, третий вообще не знает, какую команду использовать. Makefile решает это раз и навсегда.

Что такое Makefile и зачем он нужен

Makefile это файл с набором именованных команд. Вы описываете, что делает каждая цель, а потом вызываете её одним словом. Больше не нужно помнить длинные команды или держать их в заметках.

Вот базовый пример для Go-проекта:

run:
  go run .

test:
  go test ./...

lint:
  golangci-lint run

build:
  go build -o app

Теперь вместо того, чтобы каждый раз вспоминать точный синтаксис:

make run
make test
make build

Как это работает

make читает Makefile в текущей директории и выполняет команды под нужной целью. Каждая цель это метка, за которой идут shell-команды с отступом через табуляцию. Важный момент: отступ должен быть именно табом, не пробелами, иначе make вернёт ошибку.

Можно добавить зависимости между целями. Например, чтобы тесты всегда запускались после линтера:

check: lint test

Или сделать build зависимым от test, чтобы не собирать проект с непрошедшими тестами:

build: test
  go build -o app

Makefile быстро обрастает полезными целями. Несколько примеров:

.PHONY: run test lint build clean

clean:
  rm -f app

tidy:
  go mod tidy

cover:
  go test ./... -coverprofile=coverage.out
  go tool cover -html=coverage.out

Директива .PHONY говорит make, что эти цели не являются именами файлов. Без неё, если в директории окажется файл с именем build, make решит, что цель уже выполнена и ничего не запустит.

Makefile это простой способ зафиксировать рабочие команды проекта в одном месте. Новый человек в команде запускает make build и всё работает так же, как у остальных. Не нужно читать README в поисках нужной команды и не нужно помнить флаги наизусть.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

🔄 Gitea 1.26.0

Вышел крупный релиз Gitea с новыми возможностями в Actions, улучшениями интерфейса и несколькими исправлениями безопасности.

В релизе закрыты три CVE.

CVE-2026-28737 — stored XSS в просмотрщике 3D-файлов через поле extensionsRequired формата glTF.
CVE-2026-22555 — API форка позволял утечь секреты организации из-за отсутствия проверки CanCreateOrgRepo. CVE-2026-27780 — обход защиты веток через молчаливое усечение в bufio.Scanner при обработке pre-receive хука.

Actions

Пожалуй, самое заметное в релизе. Теперь поддерживается синтаксис concurrency как в GitHub Actions — новые запуски могут отменять или ставить в очередь предыдущие в той же группе. Появилась визуализация зависимостей между джобами прямо в интерфейсе. Можно перезапускать только упавшие джобы, не перегоняя весь воркфлоу.

Воркфлоу из приватных репозиториев теперь доступны как reusable. Токены Actions получили настраиваемые права по принципу минимальных привилегий. Администраторы могут приостанавливать и отключать отдельные раннеры без их удаления.

Интерфейс и работа с репозиторием

Добавили скачивание архива для поддиректории. Прямо в редакторе релизов теперь генерируются release notes из merged PR и списка контрибьюторов. В браузере файлов появились кнопки «Перейти к файлу» и «Удалить директорию».

Редактор кода переехал с Monaco на CodeMirror. Сборка фронтенда мигрировала с webpack на Vite. Появился Terraform state registry, теперь можно хранить стейт прямо в Gitea с теми же правами доступа, что и у кода.

Что важно знать перед обновлением

Несколько изменений ломают обратную совместимость. Утилита environment-to-ini удалена, вместо неё появилась подкоманда gitea config edit-ini. GET-эндпоинт для получения токена регистрации раннера удалён. Swagger-аннотации исправлены и теперь точнее описывают реальное API — если вы генерируете клиенты из спецификации, их нужно пересобрать. PUBLIC_URL_DETECTION теперь по умолчанию auto.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

⚡️ Нельзя присваивать sync.Mutex между переменными

sync.Mutex не просто структура с двумя полями. Это объект с состоянием, и если вы присвоите один мьютекс другому во время работы горутин, получите либо панику, либо гонку данных.

Что происходит при присвоении

Посмотрите на этот код:

var mu1 sync.Mutex
var mu2 sync.Mutex

// Горутина 1: захватывает mu1
go func() {
    mu1.Lock()
    defer mu1.Unlock()
    // работа...
}()

// Горутина 2: заменяет mu1 на mu2
go func() {
    mu1 = mu2 // замена мьютекса прямо во время использования
}()

Здесь два опасных сценария.

Сценарий 1: паника

Горутина 1 захватила mu1. Горутина 2 присвоила mu1 = mu2. Теперь mu1 — это чистый, незахваченный мьютекс. Когда горутина 1 дойдёт до Unlock(), она попытается разблокировать мьютекс, который никто не блокировал, и получит панику:

unlock of unlocked mutex

Присвоение переменных не создаёт отношения happens-before между горутинами, в отличие от запуска и завершения горутины. Поэтому порядок, в котором горутина 1 увидит изменение mu1, непредсказуем.

Сценарий 2: гонка данных

Если горутина 1 разблокирует mu1 в тот же момент, когда горутина 2 делает присвоение, обе одновременно записывают в поля state и sema внутри структуры sync.Mutex. Это классическая гонка данных. Итог — повреждение состояния одного или обоих мьютексов.

Как делать правильно

Не присваивайте мьютексы напрямую. Если нужно передать мьютекс в другое место, используйте указатель:

var mu sync.Mutex

// Передаём указатель, а не копию
go func(m *sync.Mutex) {
    m.Lock()
    defer m.Unlock()
    // работа...
}(&mu)

Это же правило распространяется на структуры, которые содержат sync.Mutex. Копировать их тоже нельзя. Только передавать по указателю:

type SafeCounter struct {
    mu    sync.Mutex
    count int
}

// Правильно
func increment(c *SafeCounter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

// Неправильно: мьютекс скопируется вместе со структурой
func incrementWrong(c SafeCounter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.count++
}

Инструмент go vet умеет находить такие копирования и выдаёт предупреждение copylocks.

sync.Mutex нельзя копировать или присваивать после первого использования. Передавайте мьютексы и структуры с ними только по указателю.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

🤔 Сравнили слайс с nil

На первый взгляд slices.Equal(nil, []int{}) вернёт false. Но по какой причине?

Подумайте что сравнивает slices.Equal и сравните свой ответ с нашим.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#ReadySetGo

😎 Реализации очередей для Go

В стандартной библиотеке Go нет готовых очередей. Можно написать свою на слайсах, но тогда придётся самому думать о race conditions, блокировках и сбросе состояния. Пакет queue от adrianbrad закрывает эту задачу: четыре реализации с единым интерфейсом и встроенной потокобезопасностью.

Что внутри

Все структуры реализуют один интерфейс Queue[T comparable]. Методы одинаковые у всех: Get, Offer, Peek, Contains, Size, IsEmpty, Reset, Clear, Iterator.

Четыре реализации:

BlockingQueue — FIFO с блокирующими методами. Если очередь пуста, Get ждёт. Если заполнена, Offer ждёт. Внутри использует sync.Cond. Подходит для классических producer-consumer задач.

PriorityQueue — порядок элементов задаётся функцией-компаратором. Реализована через container/heap. Полезна, когда нужно обрабатывать задачи не по порядку прихода, а по приоритету.

CircularQueue — кольцевой буфер фиксированного размера. Когда буфер заполнен, новый элемент перезаписывает самый старый. Удобна для логов, кешей скользящего окна, буферизации потоков.

LinkedQueue — связный список, O(1) на добавление и удаление. Хранит указатели на голову и хвост, поэтому не нужен обход списка.

Установка:

go get -u github.com/adrianbrad/queue

Пример BlockingQueue:

package main

import (
    "fmt"
    "github.com/adrianbrad/queue"
)

func main() {
    elems := []int{2, 3}
    bq := queue.NewBlocking(elems, queue.WithCapacity(3))

    _ = bq.Offer(1)

    elem, err := bq.Get()
    if err != nil {
        // handle err
    }
    fmt.Println(elem) // 2
}

Пример PriorityQueue:

pq := queue.NewPriority(
    []int{2, 3, 4},
    func(a, b int) bool { return a < b },
)

_ = pq.Offer(1)

elem, _ := pq.Get()
fmt.Println(elem) // 1 — минимальный элемент

Бенчмарки:

BenchmarkBlockingQueue/Get_Offer-8    27135865    47.00 ns/op
BenchmarkCircularQueue/Get_Offer-8    32379159    36.83 ns/op
BenchmarkLinkedQueue/Get_Offer-8      61257436    18.48 ns/op
BenchmarkPriorityQueue/Get_Offer-8    29347177    39.88 ns/op

LinkedQueue самый быстрый на Get/Offer. CircularQueue не делает аллокаций при операциях, что важно под нагрузкой.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

🤔 Есть ощущение, что Go незаслуженно обделён контентом на русском

Докажите обратное — кого смотрите по Golang? YouTube, телеграм — скидывайте в комменты👇 Может есть авторы c хабра, которые вам по душе?

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoTalk

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoGiggle

🔥 Недельный дайджест

Неделя спокойная, без громких новостей.

— Попросить ИИ улучшить резюме это не стратегия

— WiFi на ESP32 через TinyGo

— Gitea 1.26.0

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

👨‍💻 slices.Delete — чище, безопаснее, без утечек

Анализатор slicesdelete из пакета golang.org/x/tools/go/analysis/passes/modernize находит места в коде, где стоит slices.Delete применить вместо ручного append.

Что было раньше

Удаление элементов из среза выглядело так:

s = append(s[:i], s[j:]...)

Работает, но неочевидно. Нужно держать в голове, что именно здесь происходит, и при быстром чтении легко пропустить.

Что предлагает анализатор:

s = slices.Delete(s, i, j)

Тот же результат, но намерение читается сразу: удалить элементы с индекса i по j.

Важный нюанс

slices.Delete не просто сокращает длину среза. Она зануляет элементы между новой и старой длиной. Это защита от утечки памяти: старый append-вариант оставлял ссылки на объекты в «хвосте» среза, и сборщик мусора не мог их освободить. Именно поэтому анализатор отключён по умолчанию.

Когда включать

Если в коде нет намеренной зависимости от того, что элементы за len остаются в памяти включайте анализатор и применяйте замену. Для большинства случаев это просто улучшение читаемости и безопасности.

Включить анализатор можно через флаг при запуске:

go vet -modernize.slicesdelete ./...

или в конфигурации golangci-lint, если используете его в проекте.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

👨‍💻 GopherCon 2026

С 3 по 6 августа пройдёт GopherCon 2026. В этот раз конференция переезжает в Сиэтл.

Комитет сейчас разбирает больше 150 докладов, программа появится 4 мая. Будем следить.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

🛠 Инструментарий для работы с WebAssembly

Если вы работаете с WebAssembly и пишете на Go, раньше приходилось тянуть зависимости на C++ (wabt) или Rust (wasm-tools). Теперь есть нативная альтернатива.

Что это

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

В основе лежит пакет wasmir — семантическое представление WASM-модуля, с которым удобно работать программно.

Установка:

go install github.com/eliben/watgo/cmd/watgo@latest

Скомпилировать WAT в WASM можно одной командой:

watgo parse stack.wat -o stack.wasm

Пример работы через API

Парсим WAT-модуль и анализируем инструкции:

m, err := watgo.ParseWAT([]byte(wasmText))
if err != nil {
    panic(err)
}

for _, fn := range m.Funcs {
    for _, instr := range fn.Body {
        switch instr.Kind {
        case wasmir.InstrLocalGet:
            // обработка
        case wasmir.InstrI32Add:
            // обработка
        }
    }
}

Функции модуля хранятся в m.Funcs, каждая содержит плоский список инструкций fn.Body. Имена и типы при парсинге резолвятся в числовые индексы — так же, как это устроено в бинарном формате WASM.

Тестирование

Проект прошёл официальный тест-сьют WebAssembly — почти 200 тысяч строк WAT-файлов с описанием ожидаемого поведения. Бинарный вывод watgo прогоняется через Node.js и сверяется со спецификацией.

➡️ Источник | Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction