Как понять, что код отработал правильно

Что проверяют

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

Как отвечать

Во время выполнения правильность в Go видна через ошибки, которые возвращаются значением:

• проверка err: каждый вызов, который может упасть, возвращает ошибку, её нужно обработать или обернуть через fmt.Errorf("...: %w", err). Сравнивают обёрнутые ошибки через errors.Is и errors.As, а не через ==;
• неочевидные места: после цикла по rows.Next() нужна проверка rows.Err(), Close у записанного файла тоже возвращает ошибку, а ошибки горутин собирает errgroup из golang.org/x/sync;
• контекст: отменённый context означает, что работа не доведена до конца, и такой исход надо отличать от успеха.

До выкладки:

• тесты: пакет testing, табличные тесты с t.Run на каждый случай, httptest для HTTP-обработчиков, интерфейсы и заглушки для внешних зависимостей;
• гонки: go test -race находит гонки данных, но только на путях, которые реально выполнились в тестах;
• покрытие: go test -cover и -coverprofile показывают непроверенные ветки;
• фаззинг: встроен начиная с Go 1.18, go test -fuzz подбирает входы, на которых функция падает;
• статический анализ: go vet, часть его проверок запускается и при go test, плюс staticcheck или golangci-lint в CI.

В проде корректность подтверждают метрики и логи: доля ошибок, задержки, алерты.

Где спотыкаются

Называют golint. Он давно объявлен устаревшим и заморожен, сейчас используют staticcheck и golangci-lint.

Игнорируют ошибку через _, а потом говорят, что код «отработал». Паники не будет, код просто пойдёт дальше с нулевым значением, и об ошибке никто не узнает.

Считают, что зелёный go test -race гарантирует отсутствие гонок. Детектор ловит только то, что случилось при прогоне, поэтому тесты должны реально гонять конкурентные сценарии.