В unit тесте функция возвращает пустой срез, а ожидаемое значение задано как nil. Какой результат даст срав...

package items

import (
    "reflect"
    "testing"
)

func TestList(t *testing.T) {
    got := []string{}
    var want []string
    if !reflect.DeepEqual(got, want) {
        t.Fatalf("got %#v, want %#v", got, want)
    }
}

Краткий ответ

Тест завершится ошибкой: пустой ненулевой срез []string{} и nil-срез имеют разное представление, поэтому reflect.DeepEqual вернёт false. Нужно заранее определить контракт функции: если различие важно, сравнение корректно; если важна только пустота, проверяйте длину или используйте сравнение с соответствующей семантикой.

Исторический контекст

reflect.DeepEqual появился как универсальный механизм сравнения значений произвольных типов в стандартной библиотеке Go. Он нужен, когда обычный оператор == неприменим, например для срезов, карт и структур, содержащих такие поля.

Универсальность достигается сравнением внутренней структуры значений, а не только их прикладного смысла. Поэтому reflect.DeepEqual сохраняет различие между nil и инициализированными, но пустыми коллекциями.

Постановка проблемы

В JSON, HTTP API или бизнес-логике nil-срез и пустой срез иногда означают одно и то же: элементов нет. В других контрактах они различаются: nil может означать «значение не задано», а пустой срез — «значение задано, но элементов нет».

Если тест использует reflect.DeepEqual без решения этого вопроса, он может либо ложно зафиксировать несовместимость, либо пропустить важное различие. Особенно часто это проявляется после изменения реализации: например, функция начинает возвращать make([]T, 0) вместо nil.

Подробное решение

Для срезов reflect.DeepEqual возвращает true, если оба значения nil либо оба ненулевые, имеют одинаковую длину и соответствующие элементы глубоко равны. Поэтому var want []string — это nil-срез, а []string{} — ненулевой срез длины zero; их сравнение даёт false.

Если контракт требует различать состояния, тест следует оставить строгим и явно зафиксировать ожидаемое значение. Если контракт говорит только о количестве элементов, проверяйте len(got) == 0, предварительно обработав возможный nil: len(nil) в Go также равен нулю.

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

func TestList(t *testing.T) {
    got := []string{}
    if len(got) != 0 {
        t.Fatalf("got %d items, want empty result", len(got))
    }
}

Такой тест не проверяет, является ли результат nil, и потому устойчив к выбору представления. Обратная сторона — он не обнаружит нарушение контракта, если nil и пустой срез должны различаться.

Нельзя заменить reflect.DeepEqual на оператор == для срезов: срезы сравнимы с nil, но два произвольных среза оператором == сравнивать нельзя. Также не следует считать, что одинаковая длина гарантирует одинаковый результат: при содержательных проверках нужно сравнивать элементы.

Ситуация из практики

HTTP-обработчик возвращал поле items. Клиентский контракт требовал JSON-массив [], но после рефакторинга сервис стал возвращать nil-срез, который сериализовался как null. Тест на reflect.DeepEqual сначала был заменён на проверку длины, но это скрыло реальную ошибку формата ответа.

Рассматривались два варианта. Проверка только len была простой, но не контролировала JSON-контракт; сравнение Go-значений через reflect.DeepEqual контролировало nil-состояние, но не проверяло итоговую сериализацию. Выбрали тестирование HTTP-ответа после JSON-кодирования и отдельно нормализовали внутренние результаты там, где nil и пустота бизнес-семантически равнозначны.

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

Что кандидаты часто упускают

1. Одинаковы ли nil-срез и пустой срез при чтении?

Нет, они различаются по значению, но многие операции над ними ведут себя одинаково: len равен нулю, по ним можно безопасно выполнять range, а append работает с обоими. Различие проявляется при сравнении, JSON-сериализации и проверках, где важно состояние «не задано».

2. Можно ли безопасно сравнивать результаты через reflect.DeepEqual, если внутри есть карты?

Да, метод сравнивает карты по ключам и значениям независимо от порядка итерации. Но nil-карта и пустая инициализированная карта также считаются различными, поэтому вопрос о контракте остаётся тем же. Порядок элементов карты не должен использоваться как ожидаемый порядок в тесте.

3. Почему проверка len(got) == 0 иногда недостаточна?

Она подтверждает только отсутствие элементов. Она не выявляет, что функция вернула nil вместо обязательного пустого значения, неправильные элементы при ненулевой длине или неожиданные побочные свойства результата. Поэтому способ проверки выбирают из требования: проверка длины — для семантики пустоты, глубокое сравнение — для полного значения, проверка сериализации — для внешнего формата.