🤩 Table driven tests в Go

Обычная история: есть функция и десять сценариев. Если писать по тесту на каждый сценарий, код быстро превращается в копипасту. Table driven подход делает один тест, а сценарии складывает в таблицу.

Вы описываете кейсы в таблице, обычно это слайс структур. Потом в цикле запускаете каждый кейс как сабтест через t.Run, чтобы у каждого сценария было имя и его можно было запустить отдельно.

🟡 Пример на простой функции:

func Split(s, sep string) []string {
    return strings.Split(s, sep)
}

func TestSplit(t *testing.T) {
    tests := []struct {
        name string
        input string
        sep   string
        want  []string
    }{
        {name: "simple", input: "a/b/c", sep: "/", want: []string{"a", "b", "c"}},
        {name: "no sep", input: "abc", sep: "/", want: []string{"abc"}},
        {name: "trailing", input: "a/b/c/", sep: "/", want: []string{"a", "b", "c", ""}},
    }

    for _, tc := range tests {
        t.Run(tc.name, func(t *testing.T) {
            got := Split(tc.input, tc.sep)
            if !reflect.DeepEqual(got, tc.want) {
                t.Fatalf("want %v got %v", tc.want, got)
            }
        })
    }
}

Еще мелочь, но полезная. Внутри сабтеста t.Fatal завершает только текущий сабтест, а не весь набор, поэтому для table driven тестов это часто удобнее чем тянуть continue и пачку if.

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

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

#GoDeep